Feature Requests

When attempting to style the recently introduced BottomSheet component from @expo/ui with a opaque background color, this is only possible using the background(Color) modifiers from the respective packages. For Android there's an option though to set the containerColor prop: https://docs.expo.dev/versions/latest/sdk/ui/jetpack-compose/bottomsheet/#containercolor To make it easier for maintainers to use the universal module over the platform specific modules, would be very handy to expose this prop not only in Jetpack Compose <ModalBottomSheet> but as well for the universal <BottomSheet> . In combination with the proposal of adding presentationBackground for Swift UI this could be mapped to a modifier for the Swift UI version: export function BottomSheet({ ... containerColor }: BottomSheetProps) { ... if (containerColor) { presentationModifiers.push( presentationBackground(containerColor) ); } return (...) }

When attempting to style the recently introduced BottomSheet component from @expo/ui/swift-ui with a opaque background color, there is only the background(Color) modifier available. As this works for the main content area of the sheet when not fully expanded, it does not cover the areas exposed when dragging the sheet open. This is due to the circumstance that background(...) colors the sheet content view only while presentationBackground(...) colors the sheet presentation container itself (the system-managed surface), so color remains consistent even during interactive drag/overscroll. A test adding an expo native module to support this modifier proved it would fix the issue shown in the screenshot attached. https://developer.apple.com/documentation/swiftui/view/presentationbackground(alignment:content:) Happy to open a PR for this.

Currently, NativeTabs distributes tab widths equally across all triggers (totalWidth / tabCount). This causes label truncation when tab labels have significantly different character lengths — particularly on 5-tab layouts where one label is longer than the others (e.g. "Start Workout" alongside "History", "Profile"). Requested behaviour: An autoSize prop on NativeTabs that allows each tab to size to its label width rather than equal distribution Or a flex / weight prop on individual NativeTabs.Trigger components to allow relative sizing (e.g. flex={2} on a longer label tab) Current workaround: Developers are forced to shorten labels to fit equal-width tabs, which limits expressiveness and conflicts with standard copy. Platform reference: Android's BottomNavigationView supports labelVisibilityMode and tab width customisation. iOS UITabBar distributes widths but can be overridden via UITabBarItem appearance APIs. Exposing this through NativeTabs would bring parity with what the native platforms already support.

Both NativeTabs and NativeTabs.Trigger accepts a prop that allows you to specify which tab should be open by default when the component renders. This means you can arrange the tabs visually as you like while still setting the center tab, or any other tab of your choice, as the default tab that opens.

Building iOS Live Activities for a motorcycle ride app and keep hitting the same wall: expo-widgets@56.0.15 doesn't let me pass staleDate to ActivityKit. Native side hardcodes staleDate: nil when it builds ActivityContent, no way to set it from JS. The lock screen shows current speed + distance + elapsed time, fed by a background location task running every ~10s. Rider goes into a tunnel, GPS dies, OS may suspend the bg task entirely. The activity just freezes on whatever the last reading was. Phone shows "47 mph" for 30 minutes while the rider's at lunch. Apple's whole answer to this is ActivityContent.staleDate ( https://developer.apple.com/documentation/activitykit/activitycontent/staledate ). Once the wall clock passes it, iOS dims the UI and pauses native timers automatically. What I'd want exposed: an optional staleDate?: Date | null parameter on both LiveActivityFactory.start(props, url?, staleDate?) and LiveActivity.update(props, staleDate?). Nil keeps current behavior. We've been carrying a ~50-line pnpm patch since May doing exactly this. PR with the implementation: https://github.com/expo/expo/pull/46343 One gotcha that bit us: the PR has a prerequisite ( https://github.com/expo/expo/pull/46340 ) because expo-modules-core's Date: Convertible extension throws on Double timestamps, which is what someDate.getTime() gives you over the JSI bridge. Without the core fix the staleDate plumbing crashes at runtime with ArgumentCastException. Found that one the hard way before patching. Open to a different API shape if I missed an existing convention.

## Summary Add a way to fully suppress the dev menu (shake, Cmd+D / Cmd+M, Android dev notification, programmatic triggers) on a development build while keeping HMR, Fast Refresh, and the Metro connection intact. Ideally exposed as one of: DevSettings.setDevMenuEnabled(false) at runtime, or expo.developmentClient.devMenu: "disabled" in app.json , or EXPO_DEV_MENU=disabled env var for ephemeral CI / agent runs. ## Motivation Maestro E2E tests against a development build are increasingly common, especially in AI-assisted workflows where an agent iterates on UI, runs maestro test , reads results, and tries again. The dev build is preferred over preview/release because the rebuild cycle is seconds vs. minutes — critical for tight agent loops. The dev menu is the single biggest source of flakiness in this loop: Simulated input misfires the shake gesture Cmd+D / Cmd+M can be triggered by the harness or focus changes Android's persistent dev notification gets tapped by coordinate-based input The native SwiftUI dev menu on iOS lives in a separate UIWindow and is invisible to Maestro's text matching, so it can't be reliably dismissed from a flow Today the only "complete" mitigation is getUseDeveloperSupport() = false , which also disables HMR — defeating the purpose of the dev build. DevSettings.setIsShakeToShowDevMenuEnabled(false) exists but only covers shake. The Maestro maintainers' documented recommendation for this problem is "Perform a Release rather than a Debug build" (see mobile-dev-inc/Maestro discussion #3041 ). That works but kills the fast iteration loop that makes the dev build worth using in the first place. ## Proposed API ```ts import { DevSettings } from 'react-native'; DevSettings.setDevMenuEnabled(false); // suppress ALL dev menu entry points Or Expo-level config in app.json: ```json { "expo": { "developmentClient": { "devMenu": "disabled" } } } Fast Refresh, HMR, error overlays (optionally — agents benefit from those), and the Metro connection remain on. Only the menu is gone. ## Alternatives considered Preview/release build — too slow for agent iteration (minutes per cycle) Maestro subflow that dismisses the menu if visible — only partially works; iOS native dev menu is in a separate UIWindow and isn't matchable setIsShakeToShowDevMenuEnabled(false) — covers shake only; keyboard shortcuts and Android notification still fire getUseDeveloperSupport() = false — kills HMR, defeats the use case ## Why now Agent-driven UI iteration (Claude Code, Cursor, etc.) is a fast-growing workflow. Maestro is the de facto E2E tool for it. The dev menu is the most common cause of false-negative test runs in this loop. A single flag would remove that entire class of flake without forcing teams onto the slow release-build path. ## Repro Happy to provide a minimal repro repo on request — the behavior is reliably triggered by any npx create-expo-app + expo-dev-client + a Maestro flow that exercises gestures.

Query.exe() returns Asset instances that are thin wrappers around IDs. Retrieving actual asset metadata (uri, mediaType, duration, timestamps, dimensions) requires calling getInfo() individually on each asset. For large collections (10k–100k assets, common in photo picker UIs), this creates a 1 + N native round-trip problem that makes the new API orders of magnitude slower than the legacy getAssetsAsync. Current behavior iOS — Query.exe() fetches PHFetchResult<PHAsset>, then discards all data and returns only Asset(localIdentifier:): // Query.swift:97-106 func exe() async throws -> [Asset] { let fetchOptions = constructFetchOptions() let phFetchResult = try await fetch(fetchOptions) return sliceFetchedAssets(from: phFetchResult) .map { Asset(localIdentifier: $0.localIdentifier) } // data discarded here } Android — Query.exe() queries only _ID and MEDIA_TYPE, then wraps into Asset(uri): // Query.kt:96-109 val projection = arrayOf( MediaStore.Files.FileColumns._ID, MediaStore.Files.FileColumns.MEDIA _TYPE ) Each subsequent getInfo() call re-queries the underlying store (PHAsset.fetchAssets(withLocalIdentifiers:) on iOS, a new MediaStore cursor on Android). Environment - expo-media-library: 56.0.5 - Expo SDK: 56

Expo has strong APIs for creating, downloading, selecting, and sharing files, but there is no focused SDK API for opening a local file in the platform-native preview flow. Proposed package: expo-file-preview iOS: preview local files with Quick Look (QLPreviewController), which supports many common file types such as PDFs, images, text files, CSV files, Office documents, iWork documents, and USDZ files. Android: expose local files through FileProvider and open them with ACTION_VIEW, so - Android can launch a compatible installed app. CNG: configure Android package visibility queries for the MIME types an app previews. Fallback: compose with expo-sharing for share/export fallback when preview is unavailable. Example API: await FilePreview.openPreviewAsync(file.uri, { mimeType: "application/pdf", title: "Manual", fallbackToShare: true, }); const canPreview = await FilePreview.canPreviewAsync(file.uri, { mimeType: "application/pdf", }); This would complement existing Expo packages: expo-file-system creates or downloads the local file. expo-document-picker lets users select files. expo-file-preview previews the local file. expo-sharing shares or exports the file. Community packages such as @magrinj/expo-quick-look, react-native-file-viewer-turbo, @react-native-documents/viewer, and react-native-file-viewer show demand for this workflow and use the same native primitives. An official Expo package could provide the CNG-friendly, Expo-aligned version: local-file-first, explicit MIME types, Android package visibility config, and clear docs about Android handler-app dependence.

Through the fact that Expo Maps has been created, I would like to propose to add support for marker clusters.

We are getting warnings for prebuilds: › Using expo@catalog: instead of recommended expo@~55.0.24. › Using react-native@catalog: instead of recommended react-native@0.83.6. It would be nice to have native support for pnpm catalogs in the Expo SDK. Also for upgrading apps across our monorepo would be awesome.