Feature Requests

Currently, create-expo-app scaffolds projects with app.json by default. It would be helpful if the project creation flow offered an optional choice between: app.json (static configuration) app.config.ts (dynamic TypeScript configuration) For example: Which app configuration would you like to use? ❯ app.json (recommended for simple projects) app.config.ts (recommended for dynamic configuration) This would allow developers to start with the configuration format that best fits their project without having to manually convert later. app.json remains a great choice for simple applications, while app.config.ts is better suited for projects that need environment variables, conditional configuration, or custom logic. Providing this option during project creation would make the onboarding experience more flexible and better reflect the configuration options that Expo already supports.

Universal Button does not support a custom accessibilityLabel on Android. When the button contains custom children, such as a loading indicator, TalkBack focuses the indicator instead of the whole button. Please add an accessibilityLabel prop that maps to Android contentDescription and keeps the component exposed as a button.

Universal Text does not support React Native properties such as maxFontSizeMultiplier or allowFontScaling. Text can therefore become too large for fixed-height components such as buttons when the system font size is increased. Please provide a cross-platform way to limit the maximum font scaling on both Android and iOS.

The Android semantics modifier currently supports only contentType. Please also expose contentDescription so developers can provide accessibility labels for Jetpack Compose components such as Button and CircularProgressIndicator.

## Summary Add a first-class Android app configuration option for restricting an Expo app to tablet-sized devices. Expo currently provides ios.isTabletOnly , which configures the Xcode device family as iPad-only, but there is no equivalent option under android . ## Use case Some applications intentionally support tablets first and should not be installable on Android phones. Today this requires a custom config plugin that modifies the generated AndroidManifest.xml. ## Proposed API One possible API would be: ```json { "expo": { "android": { "isTabletOnly": true } } } Alternatively, Expo could expose a more general setting such as: ```json { "expo": { "android": { "minimumSmallestWidthDp": 600 } } } ## Expected native configuration For a tablet-only configuration, prebuild could generate an Android <supports-screens> declaration with a 600dp minimum and exclude small and normal phone screen classes, for example: ```xml <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="true" android:xlargeScreens="true" android:requiresSmallestWidthDp="600" /> ``` Using both generalized screen classes and requiresSmallestWidthDp provides compatibility with Android and Google Play filtering behavior. ## Current workaround A local Expo config plugin using withAndroidManifest can add these manifest attributes, but a first-class app-config property would provide parity with ios.isTabletOnly , schema validation, documentation, and consistent prebuild and EAS behavior.

nice to have the same feature with nativetabs freezeOnBlur

Expo UI currently includes a native "Slider", but not a "RangeSlider" (dual-thumb slider for selecting a minimum and maximum value). Since Jetpack Compose already provides a Material 3 "RangeSlider", exposing it through "@expo/ui" would enable common use cases like age, price, and distance filters while keeping the experience native and avoiding third-party libraries.

Alt prop support for web

We trigger builds (including preview builds) with an eas workflow based on github events. Our tester sometimes needs to add new devices to our ad hoc provisioning profile. They can add devices on expo.dev under our org > credentials > apple devices. They could also manually trigger a new build via the Build from GitHub functionality. The gap seems to be to refresh the provisioning profile which always requires a dev to run eas build:resign or trigger a build with the --refresh-ad-hoc-provisioning-profile flag. Allowing to do this on expo.dev as well, maybe as part of the Build from Github ui would be great. Hope I'm not overlooking anything.

Through the fact that Expo Maps has been created, I would like to propose to add support for marker clusters.