Feature Requests

Android 17 introduces the Location Button, a system-rendered button that grants precise location for the current session without a standing ACCESS_FINE_LOCATION grant. Android docs: https://developer.android.com/guide/topics/permissions/private-alternatives/location-button expo-location (including the in-progress expo-location/next rewrite) doesn't expose it yet, and I couldn't find an existing issue or community library for it. Google Play announced on April 15, 2026 an update to its Location Permissions policy. It makes the location button the recommended minimum scope for precise location, with the change taking effect on January 27, 2027. Many Expo apps request precise location only for one-off, in-session actions ("use my current location", check-in, nearby search). Those apps will likely be expected to use the location button instead of requesting ACCESS_FINE_LOCATION. Without first-party support, every affected app has to write and maintain its own native module before the deadline. PROPOSED API (ROUGH IDEA) A native view component exported from expo-location (or expo-location/next), for example: <LocationButton onResult={({ granted }) => { ... }} /> An availability check, so apps can fall back to the existing permission flow on Android 16 and below and on iOS, for example: Location.isLocationButtonAvailable() // true only on Android 17+ OPEN QUESTIONS Which appearance options should be exposed as props, as far as the platform allows customization? How should a session grant be reported by getForegroundPermissionsAsync() and useLocationForegroundPermissions()? With the expo-location/next rewrite underway, it would help to know whether this is planned and roughly which SDK version it might land in. My Team need to decide soon whether to wait or build their own wrapper before January. Happy to help.

## Summary Please make the data shown in EAS Insights > App usage available through a documented, token-authenticated API, so we can pull it into our own dashboards on a schedule. ## Use case We ship a production app with expo-insights , with about 20k monthly active users on iOS and Android. We are building an internal dashboard that combines Insights with App Store Connect and Google Play data. It answers three questions: How many people use the app each month? How fast does each release get adopted? How many users get left behind when we raise the minimum OS version? Insights is the only source that counts active users across every installed version of the app. EAS Observe only covers builds on SDK 55 and later. App Store Connect only counts users who share analytics with developers, and Google Play counts installs rather than active users. ## Current workaround The Expo website reads these GraphQL fields, and they work with a robot access token: app.byId(appId).insights.totalUniqueUsers(timespan) app.byId(appId).insights.uniqueUsersByPlatformOverTime(timespan) app.byId(appId).insights.uniqueUsersByAppVersionOverTime(timespan) They are undocumented and eas-cli does not use them, so we cannot rely on them staying stable. ## What would help Official, documented access to the existing App usage metrics with a robot access token. A versioned GraphQL schema or a REST endpoint would work. So would an eas insights:* command with JSON output, like eas observe:* . App versions broken down by platform. Today the per-version series mixes iOS and Android, so we can't tell which platform the users of an old version are on. An OS version breakdown. expo-insights already sends os_version with every APP_LAUNCH event (the iOS version on iOS, the API level on Android), but neither the dashboard nor the API exposes it. Unique users per OS version, and per app version and OS version, would show how many users a minimum OS bump leaves behind. Documented semantics. What counts as a unique user (one per EAS client ID, so one per install?), the timezone and boundaries of daily and hourly buckets, and the retention period. We currently see about 365 days of history. Optionally, a way to tell app variants apart. The event carries no bundle identifier, so dev, test and production builds that share one EAS project are counted together.

Contact.presentPicker() opens the OS contact picker, but the picker's own result is thrown away and only the contact id is kept. getDetails() then re-queries the contact store, which requires READ_CONTACTS on Android and full Contacts authorisation on iOS. Both OS pickers already return the selected contact's data without any permission. Because expo-contacts re-fetches instead of using that data, every app that only needs "pick one contact" is forced to hold a permission it doesn't need. Google Play's Contacts Permission policy restricts READ_CONTACTS for apps targeting Android 17 (API 37). Enforcement begins 27 January 2027 . Apps whose only use is selecting a contact are told to remove the permission and use the Android Contact Picker . expo-contacts currently offers no way to do that. On iOS the same design means users see the "Allow access to all contacts" prompt for what is a single-contact pick, and iOS 18 limited access can leave the picked contact unreadable ( Failed to find a contact with id ).

Contacts need to be searched over directly in the app in 99% of cases. Fetching 1000 contacts takes forever. Searching and/or sorting those contacts takes forever. Native contact picker is really fast. Here's a plugin you can look at to start with: https://github.com/LynxITDigital/react-native-contacts-wrapper This solves several related feature requests.

Add scripts for submit lifecycle, like there is on build, so we can hook callbacks to update status on a CI. Something lke eas-submit-start and eas-submit-success (or eas-submit-failure ).

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.