Feature Requests

Please expose a public native API in expo-secure-store (e.g. a Swift SecureStore type and a Kotlin SecureStore(context) class with getItem / setItem / deleteItem) that reads and writes the same items as the JS API. Why: our React Native app has native code that needs the same auth token that JS stores, including before the JS runtime starts or when there is no React context at all (push handlers in didFinishLaunching / onNewToken, Android WorkManager jobs and notification-action receivers, a native networking layer that refreshes the token). We want a single secure copy of the token shared by JS and native. Today this isn't possible: on iOS the Keychain helpers in SecureStoreModule are private, and the service name ("app" plus the ":auth"/":no-auth" suffix) is an internal detail. On Android all state is created in OnCreate from the React context, so the module doesn't exist in a process without JS, and the storage format (encrypted JSON, keystore aliases, legacy schemes) is internal. That format may also change if SecureStore moves to DataStore, as requested in other posts here. Our only options are re-implementing Keychain/Keystore storage ourselves or patching the package on every SDK upgrade. Items without requireAuthentication would be enough for us; synchronous or suspend variants both work.

In a vertical short-video feed built on a pool of VideoPlayers (next clip loaded with replaceAsync and paused), calling play() on the preloaded player takes ~200 ms before the clock moves (measured on iOS 26.4, expo-video 57.0.4, clip readyToPlay with its first segments buffered, warm CDN). The first frame is already on screen, but motion and audio lag the swipe. AVFoundation's answer is AVPlayer.preroll(atRate:completionHandler:), which primes the media pipelines of a paused, readyToPlay player so a following play() starts with minimal latency. playImmediately(atRate:) is the related API for starting without the stall-avoidance wait when the app knows data is buffered. Request: player.prerollAsync(rate?: number): Promise<boolean> on iOS (resolving with the completion's finished flag, rejecting or resolving false if the player isn't readyToPlay), and optionally playImmediately(rate?). On Android it could resolve false, or map to ExoPlayer's prepare() if that's already done. Today neither is reachable from JS, and bufferOptions.waitsToMinimizeStalling: false isn't a substitute: with it off, a play() issued before the item has data never starts (documented AVPlayer behaviour, and it reproduces reliably). Checked in 58.0.3 and the latest canary: no preroll/playImmediately in the package.

UIKit's zoom transition (UIViewController.Transition.zoom) is available on tvOS 18. It fits the focus-driven UI well: a focused poster can zoom into its detail screen, the same way Link.AppleZoom works on iOS today. expo-router's native module is only built for iOS, though. ExpoRouter.podspec lists iOS as its only platform, and link/preview/native.tsx disables the native views when Platform.isTV is true. I tried building the module for tvOS. It gives 53 compile errors in 9 files, and only 2 of them are in the zoom code (the availability check needs tvOS 18.0). The rest come from features that tvOS doesn't support: Head: the CoreSpotlight search APIs are unavailable on tvOS Link previews: context menus need tvOS 17, and the commit animations are unavailable Toolbar: the toolbar item APIs are unavailable on tvOS Would you accept tvOS support for the zoom transition, with those features left out on tvOS? I'm happy to send the PR.

When a project has the Supabase integration connected, the build details page ( expo.dev → Project → Builds → [build]) shows Supabase advisors (security and performance findings). Unlike the regular build logs, these advisors can't be copied easily, so sharing or acting on them means retyping or awkwardly selecting text. Proposal: Add a "Copy as Markdown" button to the Supabase advisors section that copies all findings to the clipboard as Markdown: Grouped by category (e.g. ## Security , ## Performance ) Each finding with its level (error/warning/info), title, description, and affected object (table, function, policy) Remediation links preserved Optionally, a copy button on each individual finding as well Why: Makes it easy to paste advisor findings into GitHub issues, PRs, Slack, or Discord Lets developers hand findings straight to AI coding assistants to fix Build logs already support copying, so the advisors section feels inconsistent without it

DockedSearchBar currently only supports a LeadingIcon, even though a TrailingIcon should be possible. This would allow adding a clear button to the search bar.

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

Use case: our app receives data-only FCM pushes ("X followed you", chat messages). The user taps one while the app is killed. The tap should open the target screen with a working back stack. There is no supported way to do this through the linking layer today. A notification tap launches the app with no URL. In bare React Navigation the documented fix is to customize linking.getInitialURL to await messaging().getInitialNotification() and return the target path, so the tap builds initial navigation state. Expo Router owns the linking prop and hardcodes getInitialURL; when there is no URL it substitutes the root URL. The comment next to that fallback in expo-router/build/link/linking.js says it directly: // The path will be nullish in bare apps when the app is launched from the home screen. // TODO(EvanBacon): define some policy around notifications. redirectSystemPath in +native-intent only rewrites a path that already exists, so it cannot fill this in. The workaround everyone lands on is dispatching imperatively (router.push inside the notification-open handler). On a cold start that dispatch can fire inside the window where nested navigators have not yet registered into the container. The action then resolves against a bare root and stacks a second copy of the entire app: no back button, dead swipe-back, user stranded. Deterministic for us in a release build. We now hold the route and poll getRootState() until the shell is registered, which works but should not be app code. Related upstream ask: react-navigation/react-navigation discussion #13264. Request: an officially supported +native-intent hook for the no-URL launch, for example an async getInitialPath() (or calling redirectSystemPath with a null path and accepting a returned one), so a notification tap can resolve its target and enter through initial state like any other deep link. Ideally it only delays first render when the launch actually came from a notification.

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

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.