Feature Requests

While expo-image now supports clearing the cache and specifying a custom cacheKey via the source prop, there is still no official way to manually write or seed an image into the cache engine programmatically. We need an API that allows us to inject a local image file (e.g., from expo-image-picker or expo-file-system) into expo-image's disk/memory cache under a designated cacheKey.

Workflow jobs often have to connect to other providers like AWS, Google Cloud, Azure, Tailscale, etc. to perform operations: download files, update a config... As of right now, the only way to do so is to create long-lived credentials (that can be stolen and exploited) and store them in the project's environment variables. The best practice for this would be to be able to generate a token from Expo which has appropriate subject and claims in workflow jobs, which can then be validated and trusted by other services.

We already have good skills, and most apps are developed with the assistance of coding agents. I feel like it's a DX no-brainer XD.

React native alreday supports this. Expo is blocked by this: https://github.com/expo/expo/blob/sdk-56/templates/expo-template-bare-minimum/android/app/build.gradle#L11-L21

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. 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 Implementation note for anyone reviewing: the JS Date is passed over the JSI bridge as a millisecond timestamp and converted to Date at the expo-widgets module boundary (Double? → Date(timeIntervalSince1970:)), so the PR is self-contained — it works without any change to expo-modules-core. (Earlier versions of this patch relied on a Date: Convertible fix in core, because that extension throws an ArgumentCastException on the Double timestamps getTime() produces over the bridge. Converting at the boundary sidesteps that entirely for staleDate.) That core bug is still real and worth fixing on its own — the existing LiveActivity.end() path passes JS timestamps straight into Date? params and hits the same cast exception — so there's a separate, independent PR for it: https://github.com/expo/expo/pull/46340 . It's no longer a prerequisite for staleDate, just a related cleanup.

## 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.