Feature Requests

At this moment, @expo/ui menus always come with a purple-ish looking.

When using a font family with multiple files for each font weight and style, the CSS rules generated for the web export is incorrect and does not properly define the font family. Given a single font family (e.g. "Wix Madefor Text") with multiple files (e.g. "fonts/WixMadeforText-Regular.woff2", "fonts/WixMadeforText-Italic.woff2", "fonts/WixMadeforText-Bold.woff2"), we should be able to define a config for useFonts as: useFonts([ { fontFamily: "Wix Madefor Text", fontDefinitions: [ { path: require("@/assets/fonts/WixMadeforText-Regular.woff2"), }, { path: require("@/assets/fonts/WixMadeforText-Italic.woff2"), style: "italic", }, { path: require("@/assets/fonts/WixMadeforText-Bold.woff2"), weight: 800, }, ] } ]) The CSS should generate as: @font-face { font-family: 'Wix Madefor Text'; src: url("fonts/WixMadeforText-Regular.woff2"); font-display: auto; font-weight: 400; font-style: normal; } @font-face { font-family: 'Wix Madefor Text'; src: url("fonts/WixMadeforText-Italic.woff2"); font-display: auto; font-weight: 400; font-style: italic; } @font-face { font-family: 'Wix Madefor Text'; src: url("fonts/WixMadeforText-Bold.woff2"); font-display: auto; font-weight: 700; font-style: normal; }

The request here is for a simple escape hatch from Expo Router for files or folders within the /app directory. This would be modeled after the same transition made in web, most notable Next JS' move from the /pages router (slices) to /app router (co-location). e.g. my-app/ └── app/ └── posts/ ├── _components/ │ ├── PostBody.tsx │ └── AuthorCard.tsx ├── _hooks/ │ └── usePostData.ts ├── index.tsx <-- Route definition └── [slug].tsx <-- Route definition Application slices (Routes as /app, components/ + hooks/ + services/ etc all as mirrored directories) require tremendously more overhead and expose opportunities for divergence as an app grows as compared to co-location as displayed above. Allowing folders and files to be escaped allows for everything pertaining to a specific feature to exist in the same place, elevating only elements that are truly shared in other places to a more global space. What we have now is the equivalent of enforcing everything as "global state". This is very similar to how we already view scoping within code itself- place variables as close to where they are used as possible. https://x.com/kentcdodds/status/1140985711052484608

## Summary Add a visual component selector in Expo Go — similar to Cursor’s browser selector — so developers can tap UI on device/simulator and send that component (or a set of components) into their AI coding tool / editor for targeted edits. ## Problem When iterating on React Native UI in Expo Go, it’s hard to map what you see on screen to the exact component/file in the codebase. You end up describing layouts in chat (“the card under the header on the profile screen”) instead of pointing at the real component tree. Cursor already solves this for web with a selector that attaches selected DOM/components to chat; Expo Go doesn’t have an equivalent. ## Proposed solution In Expo Go (and ideally expo-dev-client), add a “Select component” mode that: Overlays the running app so you can tap a view Highlights the selected React Native component / fiber Resolves source location (file + component name) when available Lets you multi-select a set of components Exposes an action to copy / send selection context to an editor or AI chat (component name, props summary, source path, maybe a small tree snippet) ## Why this matters Faster AI-assisted UI edits (“fix this button spacing” with the real component attached) Less guessing between visual UI and source files Better DX parity with modern web tooling (Cursor selector, React DevTools inspect) ## Related existing tools React Native DevTools / element inspector help inspect, but they’re not optimized for “select → attach to AI chat / edit this component.” This would be a first-class selection → context handoff flow for Expo’s AI/editor workflows. ## Platforms iOS + Android Expo Go; ideally also custom dev clients.

## Issue When the location permission is set to "Ask every time" , expo-location returns a ** denied ** status. However, the permission is not actually denied. Android is configured to prompt the user each time the app requests location access, so reporting it as denied is misleading. Expected behavior: When the permission is set to "Ask every time" , expo-location should return a status that reflects this state (or otherwise indicate that the permission can still be requested), instead of denied . ### Steps to reproduce Install an app using expo-location . Grant the location permission once. Open the Android app settings and change the location permission to "Ask every time" . Reopen the app. Call Location.getForegroundPermissionsAsync() . Current behavior: The returned permission status is denied . Expected behavior: The status should not be denied , since the permission is configured to prompt the user on each request.

The new class-based API (expo-media-library 57) can't replace legacy getAlbumsAsync() for building an album picker: No smart albums on iOS. Album.getAll() uses PHCollectionList.fetchTopLevelUserCollections, so Recents, Favorites, Videos, Screenshots, etc. are unreachable. Legacy had getAlbumsAsync({ includeSmartAlbums: true }). No asset count. Legacy Album.assetCount is gone; the only way to count is fetching every asset in the album (album.getAssets() or Query.album(...).exeForMetadata()). No bulk album metadata. Titles require one async getTitle() round-trip per album, and album type (smart vs. user) isn't exposed at all. Use case: a Google Photos–style picker header listing albums with title + count, smart albums first. Assets migrate cleanly to Query.exeForMetadata(), but albums force us to keep importing expo-media-library/legacy.

Summary The Image component in @expo/ui/swift-ui currently supports: systemName (SF Symbols) assetName (Custom SF Symbols / Symbol Sets) uiImage (local file URI) However, there is currently no way to display bundled image assets such as PNG files included in the app. Use case When building widgets with expo-widgets , it's common to use custom illustrations, mascots, or branded graphics instead of SF Symbols. For example, I have a bundled asset: src/assets/widgets/mo-with-cup.png In React Native, this can be displayed with: <Image source={require('./mo-with-cup.png')} /> There doesn't appear to be an equivalent API in @expo/ui/swift-ui . Suggested improvement It would be great if @expo/ui/swift-ui exposed the equivalent of SwiftUI's Image("assetName") API for bundled assets. For example, a JavaScript API could look like: <Image imageName="mo-with-cup" /> or any other API that allows displaying bundled image assets. The exact API design is less important than exposing the underlying SwiftUI capability. Why this would help This would make it much easier to build widgets with custom illustrations, mascots, branded graphics, and other bundled assets without requiring file:// URIs or converting images into custom SF Symbols.

For example, my folder structure is like this: app -- |-- _layout.tsx |-- users -- | -- [id].tsx |-- (tabs) |-- components |-- utils I don't want my components and utils folder appeared in my router. Any idea? Thanks.

While file-based routing may work for the majority of people, it’s not great for everyone. You can’t exclude screens conditionally for example. With non-file based routing this is possible. I think this would be a great addition.