Feature Requests

The state persistence feature help a lot during the development. Here is the link to the docs: https://reactnavigation.org/docs/state-persistence/

### Summary As an active educational application ( com.senaysoft.* ), we are implementing the alpha expo-age-range module to comply with emerging state-level age-assurance regulations. While the Android implementation (Play Age Signals) is working perfectly, the iOS implementation currently forces a steep architectural and UX trade-off due to two major blockers. We are currently forced to exclude the package from our iOS autolinking to maintain our build pipeline. We are opening this issue/discussion to highlight the exact friction points preventing production adoption on iOS. ### Blocker 1: Xcode 16 / Swift 6 Strict Concurrency Failures Standard EAS build environments utilizing Xcode 16 / iOS 26 SDK enforce strict Swift 6 concurrency by default. The current expo-age-range alpha pod does not pass these checks. The Failure: During the Run fastlane step, the compiler throws the following error inside the ExpoAgeRange target: task or actor isolated value cannot be sent Current Workarounds (Both Fragile): Abandon the iOS implementation entirely via expo.autolinking.ios.exclude . Write a custom Config Plugin utilizing @expo/config-plugins ( withDangerousMod ) to inject Ruby into the post_install Podfile block, forcing SWIFT_STRICT_CONCURRENCY = 'minimal' for the pod. The Request: Please update the internal Swift files ( AgeRangeModule.swift , etc.) to comply with Apple's actor isolation rules or apply @preconcurrency annotations so standard EAS cloud builds compile cleanly out of the box. ### Blocker 2: JS Exposure of Jurisdiction Eligibility ( isEligibleForAgeFeaturesAsync ) To prevent severe UX degradation for a global educational app, we need to be able to silently bypass the native age gate modal for users in non-regulated regions. The Issue: Because the alpha module currently lacks JavaScript access to Apple's isEligibleForAgeFeaturesAsync() pre-check (or equivalent), our fallback logic must aggressively fire requestAgeRangeAsync() for every single user globally running iOS 26+. The Request: Prioritize exposing the eligibility check to the JS bridge. This is critical for allowing us to ping the OS ("Is this user in a regulated jurisdiction?") before needlessly triggering the native Apple age gate for global users who fall outside the scope of Texas/Utah/Louisiana laws. ### Environment Expo SDK: 54 (Alpha track) React Native: 0.81.5 Package: expo-age-range (~0.2.1) Platform: iOS (EAS Build / Xcode 16)

## Summary @expo/ui/swift-ui/modifiers exposes accessibilityLabel , accessibilityHint , accessibilityValue , and recently accessibilityHidden / accessibilityIdentifier — but there is no way to set a view's VoiceOver speech language . In multilingual apps where the in-app UI language can differ from the device language, VoiceOver pronounces SwiftUI labels with the device-language voice, producing garbled speech. ## Use case A language-learning app where users pick the app interface language independently of the device language. For React Native views we use the accessibilityLanguage prop (BCP-47) so VoiceOver reads each element in the correct language. There is no equivalent for @expo/ui SwiftUI components — e.g. a Menu with Button items whose labels are already localized text but get read in the wrong accent. ## What we tried No accessibilityLanguage / speech-language modifier exists in @expo/ui/swift-ui/modifiers . accessibilityLabel(label: string) only takes a plain string , so we can't pass an AttributedString carrying accessibilitySpeechLanguage . environment('locale', '<bcp47>') makes VoiceOver pronounce the ** Menu trigger label in the given language ✅, but it does not** reach the Menu 's presented popup items; per-item environment('locale', …) had no effect on the items either. ## Proposal Add an accessibilityLanguage(bcp47: string) modifier mapping to SwiftUI's accessibility speech language (e.g. an AttributedString with accessibilitySpeechLanguage , or the underlying UIKit accessibilityLanguage ), in a way that also propagates to a Menu 's presented items. ## Environment @expo/ui : 56.0.14 expo : ~56 react-native : 0.85.3 Platform: iOS 26 (SwiftUI Menu )

Booking of Event Requesting For private Meeting &VIP

At the moment it's not possible to customize the text "recording" that is hardcoded in the Android foreground service when recording. As we need internationalization in our App we can't use the built-in foreground service at the moment.

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 (...) }