Feature Requests

DESCRIPTION: react-native-webview is widely used, but maintenance feels stale. Critical issues like https://github.com/react-native-webview/react-native-webview/issues/3776 and https://github.com/react-native-webview/react-native-webview/issues/3825 have been open for a long time. Expo already ships @expo/dom-webview for DOM components ( https://www.npmjs.com/package/@expo/dom-webview ), but it does not have full feature parity with react-native-webview and is scoped to DOM components. Proposal: ship a first-class expo-webview at the same quality bar as expo-file-system, expo-location, and expo-notifications. Use case I had not used WebViews much until I needed to embed an existing e-commerce site in Expo and communicate over postMessage. Many teams cannot afford to rewrite their web storefront in React Native. WebViews are not only useful for privacy-policy screens — they are a practical way to ship existing web apps inside Expo while adding native capabilities (Apple Pay, etc.) via postMessage. I am not alone: others in the Expo community are running into the same class of problems. This Discord thread describes an Expo Router app that wraps an existing mobile-friendly website with tabbed WebViews — the first tab loads fine, but others often hang mid-load or fail to load images; on iOS, incognito={true} fixes loading but breaks shared login state across tabs: https://discord.com/channels/695411232856997968/1360649231576338542 If you are doing something similar — loading a WebView, communicating with postMessage, and exposing native features to a web app that will not be rewritten soon — please comment and upvote. Baseline expectations postMessage(string) — apps define their own message shape; I typically use { type: 'web/feature/action', payload: any } and receive { type: 'native/feature/actionSuccess|Failure' } Pull to refresh Back navigation Overall stability comparable to what native developers get from platform WebViews Suggested architecture see attachements On iOS, WWDC 2025 introduced a native SwiftUI WebView via WebKit for SwiftUI (iOS 26.0+), reducing the need for custom UIViewRepresentable wrappers around WKWebView. Prior art / references NativeScript WebView: https://github.com/NativeScript/NativeScript/tree/b699794db88bb92e1e2a739ea0ad4fe19df58625/packages/core/ui/web-view react-native-webview issues: https://github.com/react-native-webview/react-native-webview/issues Flutter webview_flutter: https://pub.dev/packages/webview_flutter Flutter flutter_inappwebview: https://pub.dev/packages/flutter_inappwebview KMP compose-webview discussion: https://slack-chats.kotlinlang.org/t/32852048/hi-everyone-wave-excited-to-share-compose-webview-a-feature- kmp-webview: https://github.com/HarlonWang/kmp-webview compose-webview: https://github.com/parkwoocheol/compose-webview compose-webview-multiplatform: https://github.com/KevinnZou/compose-webview-multiplatform Others https://expo.canny.io/feature-requests/p/react-native-webview-support https://expo.canny.io/feature-requests/p/update-react-native-webview https://expo.canny.io/feature-requests/p/reduce-os-memory-reclaim-for-webview-heavy-apps-fix-new-architecture-default-on https://expo.canny.io/feature-requests/p/expo-increase-react-native-webview-expected-version-range-for-expo-sdk33-to-be-7

I use E2E a lot, and sometimes the Dev Menu is just in the way, so, to make it easier to hide, for me and for LLMs, I would like to add consistent test ids to them. Glad to open the PR if the team is open to review it.

Sometimes with agents, when using the Metro Bundler, it will wait for the developer to pick a metro server, but sometimes the LLM get stuck and won't move automatically. So, I wish there was a checkbox to enable "auto select metro", and as soon as it has one metro available, it starts a 5s timer or something and picks that one. Glad to help with the development of it

Hi, currently implementing age range logic using expo-age-range. The general age range validation works great. My issue is that on iOS, when detecting if there is a significant change that needs approval there is no way to see the status of said significant change. There is no approved/denied/pending, just that there is a significant change. This is specifically a case I'm trying to implement for minors 13-17. If there is a significant change it should be approved/denied by a guardian and the app should be able to response to those test cases. On Android, this isn't an issue since significantChangeStatus returns with a value which can be acted on. It would be great if this package (expo-age-range) could offer the ability to see the current status of the significant change approval for iOS.

@expo/ui Host has no way to opt out of Material You dynamic colour on Android. HostView.kt uses dynamicLightColorScheme(context) / dynamicDarkColorScheme(context) on any API ≥ 31, and the existing colorScheme prop only selects light vs dark — both branches still pull the wallpaper palette. Apps with a fixed brand palette therefore can't make Host match the rest of their UI. MaterialExpressiveTheme(colorScheme = …) already takes a ColorScheme, so an optional colors prop (or dynamicColor={false}) would be additive and non-breaking.

We run a production Expo app (SDK 54) that wraps a heavy web app in react-native-webview. Our main ask is framework support for background memory, plus two things from the SDK 54 upgrade that caused a production regression: Background memory reclaim (the main ask). For WebView-heavy apps, the OS reclaims the backgrounded app/WebView under memory pressure, forcing a full cold relaunch on return. This is OS behavior, but it's a supported Expo use case. We'd like framework-level support: reducing background memory footprint, and/or a supported way to retain and restore WebView state across an OS-initiated process kill. Bundled react-native-webview version. SDK 54 shipped 13.15.0, which carried a WebView recovery crash (fixed upstream in 13.16.1/13.16.2). Bundling a webview version with a known crash caused a regression for us. New Architecture default. Our config set newArchEnabled: false scoped to Android in expo-build-properties, but after the SDK 54 upgrade the iOS build was on the New Architecture anyway. An SDK upgrade silently switching a build's architecture, without an obvious cross-platform signal, is easy to miss and hard to diagnose. Please make newArchEnabled behavior explicit and consistent across platforms. Environment: Expo SDK 54, react-native-webview (moving to 13.16.x), iOS + Android, production.

Summary expo-image-picker currently always opens the system picker with an empty selection state. There is no way to pre-check previously selected assets when reopening the picker (e.g. when the user taps "Change selection" after already picking photos). On iOS, the underlying PHPickerViewController supports this natively via PHPickerConfiguration.preselectedAssetIdentifiers (iOS 15+), but expo-image-picker does not expose any option to pass preselected asset IDs. Use case A common pattern in photo apps is to let users pick multiple photos, review them, and then reopen the picker to add/remove items. Users expect their previous selection to still be checked inside the native picker, not to have to reselect everything from scratch. Requested API Add an optional field to ImagePickerOptions, e.g.: preselectedAssetIdentifiers?: string[]; // asset IDs to pre-check in the picker Behavior: On iOS, map this to PHPickerConfiguration.preselectedAssetIdentifiers. On Android, either no-op (if no equivalent exists) or use the closest available equivalent. References Apple PHPickerConfiguration.preselectedAssetIdentifiers: https://developer.apple.com/documentation/photokit/phpickerconfiguration/preselectedassetidentifiers expo-image-picker docs (no such option exists today): https://docs.expo.dev/versions/latest/sdk/imagepicker/

More and more supply chain attacks are causing many organizations to require a min-release-age setting in their NPM configuration (and I presume pnpm, yarn, etc). Expo doctor should not recommend updating dependencies that are too new according to those rules because this fails to fetch via NPM and forces us to have to manually find all dependencies that satisfy the version ranges but are older than X days.

Alt prop support for web

For applications that requires audio output accuracy (e.g. metronome, drum machine), real-time (PCM) buffer audio output support is required to deliver sample-level accuracy. As comparison: In Qt we can use QAudioSink::start(Callback &&cb) to achieve that In Web Audio API we can use AudioContext + AudioBuffer to achieve that. In Android we have AudioTrack.StreamEventCallback In JUCE we can implement getNextAudioBlock() It could be great if expo-audio have similar API that allows developer to do so.