Feature Requests

The legacy API can filter assets by media subtype on iOS: getAssetsAsync({ mediaSubtypes: ['screenshot'] }), added in https://github.com/expo/expo/pull/36756 . The new Query API has no equivalent: AssetField only covers creationTime, modificationTime, mediaType, width, height, duration and isFavorite. The new API can read the subtypes of a single asset with asset.getMediaSubtypes(), but it can't ask for "all screenshots" or "all Live Photos". The only way is to call getMediaSubtypes() on every asset in the library, which is slow for large libraries. PhotoKit supports the filter natively with a predicate on mediaSubtypes, which is what the legacy implementation does. Use case: my app lets people sort their photos by type (screenshots, Live Photos, portraits, panoramas, slo-mo videos). Today I need the legacy API for that one call, while everything else uses the new API. Proposal: support subtypes in Query, for example: new Query().within( AssetField.MEDIA _SUBTYPES, [MediaSubtype.SCREENSHOT, MediaSubtype.LIVE _PHOTO]).exeForMetadata() It would match assets that have any of the given subtypes ((mediaSubtypes & mask) != 0), like the legacy option does. On Android it could match nothing or throw, the same as the legacy option, which is iOS only. Related: https://expo.canny.io/feature-requests/p/expo-media-library-new-api-album-listing-lacks-smart-albums-asset-counts-and-bul

As an indie developer, I’ve built my app with Expo and released it worldwide. I recently noticed that HarmonyOS now has over 100 million users, but unfortunately, Expo doesn’t support HarmonyOS development yet. I really don’t want to miss out on this emerging market, so I had no choice but to ditch Expo and switch to bare React Native. Honestly, it’s a real bummer. I truly hope Expo can add HarmonyOS support as soon as possible — the moment it does, I’ll be switching back in a heartbeat!

With presentation="inline", DateTimePicker shows Material 3's built-in title ("Select date") and the large date headline above the calendar, with no way to remove them. Material 3's DatePicker takes title and headline slots that can be set to null, but DatePickerView.kt never passes them, so they always show (as of 58.0.14 and main). When the calendar sits in a sheet or screen that already has its own title, they're redundant and push the calendar down. iOS already handles this: since expo/expo#37665, the picker hides its label when no title is passed. Please add the Android equivalent, either an option like showHeadline={false} or the same no-title behaviour, that passes title = null, headline = null. If it would help get this sooner I'm open to submitting a PR.

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

Our product has started to be compatible with HarmonyOS. However, we have noticed that expo does not support HarmonyOS for the time being. Are there any migration plans?

HarmonyOS is the next iOS and a new Expo growth point. RN support is already there, but Expo needs to absorb it to unify the mobile development process. https://gitee.com/openharmony-sig/ohos_react_native/blob/master/docs/en/README.md

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