Feature Requests

NativeTabs.Trigger does not expose a stable, documented prop for assigning a test identifier to the native tab bar item. There is an unstable_nativeProps escape hatch, but this is explicitly unstable and forwards raw react-native-screens props. This makes it unsuitable as a long-term testing interface. JavaScript tabs already support tabBarButtonTestID via @react-navigation/bottom-tabs, but NativeTabs.Trigger has no equivalent. Use case: We use Maestro for E2E testing. Currently, native tabs can only be targeted using text selectors (e.g. tapOn: "Dashboard"), which breaks with localization. We need stable, testID-based selectors like the rest of the app. Proposed solution: Add a stable prop such as: tabBarButtonTestID?: string (preferred for parity), or testID?: string This should map to the underlying native tab bar item test identifier.

When opening the dev client, the field for the server address always shows the http://localhost:8081 placeholder text. When pressing the connect button, I get a warning that "" is an invalid URL host. In my case, I use my physical Android device via cable so the address is actually localhost:8081 as our test devices are not allowed to be in our internal network. So I have to type it in all the time even though the placeholder suggests that this exact address would be the default. Is there any concern setting the default value for the host to be actually what the placeholder implies?

Lock screen controls for AudioPlaylist. This would result in Parity between the AudioPlayer and AudioPlaylist.

Would love to see support for iOS configurable widgets in expo-widgets — the "Edit Widget" flow where users long-press and pick what data the widget shows (e.g. selecting a habit, a city, an account). This uses AppIntentConfiguration / ConfigurationAppIntent on the native side.

Stack.Toolbar supports left, right, and bottom placements. SwiftUI also supports .toolbar(placement: .keyboard) for attaching toolbar items above the keyboard. This placement is missing from Expo Router. Common use cases: Done/dismiss buttons for numeric keyboards, formatting toolbars, quick-action buttons above the keyboard.

Summary expo-audio currently lacks the ability to stream raw PCM buffers from the microphone in real-time. This is a critical missing feature for use cases like live speech recognition, audio analysis, waveform visualization, and WebSocket audio streaming. Current Behavior expo-audio supports basic recording and playback, and provides PCM samples for playback visualization — but there is no way to receive a continuous stream of raw PCB buffers from the microphone during recording. Expected Behavior Developers should be able to receive a real-time callback with raw PCM Float32Array buffers as audio is being captured from the microphone. Proposed API const { startRecording, stopRecording } = useAudioRecorder({ sampleRate: 16000, channels: 1, onPCMData: (buffer: Float32Array, sampleRate: number) => { // send to WebSocket, run through ML model, visualize waveform, etc. } }); Proof of Demand I built and published expo-audio-stream-pcm ( https://www.npmjs.com/package/expo-audio-stream-pcm ) specifically to fill this gap. The library already has a working native implementation in Kotlin (Android) that delivers real-time PCM buffers via a callback. Other community packages solving the same problem: @siteed/expo-audio-studio expo-audio-stream (mykin-ai) @speechmatics/expo-two-way-audio The existence of multiple community packages solving the same problem is strong evidence this belongs in the official SDK. Use Cases Live speech-to-text (OpenAI Whisper, Google Speech, etc.) Real-time audio waveform visualization WebSocket audio streaming to a backend On-device ML audio analysis Willingness to Contribute I am willing to submit a PR implementing this feature, porting my existing Kotlin implementation into expo-audio and adding the corresponding iOS (Swift) implementation to match.

## Summary expo-audio does not expose MPNowPlayingInfoPropertyIsLiveStream , which means live radio and streaming apps cannot show the native iOS LIVE indicator on the lock screen and Control Center. Instead, iOS renders a broken scrubber with no duration, which is incorrect UX for live streams. ## Environment Expo SDK: 55 expo-audio : ~55.0.8 Platform: iOS Use case: Live radio stream (no duration / infinite stream) ## Expected behavior When playing a live stream, the lock screen and Control Center should show: A LIVE badge instead of a progress scrubber No elapsed time or duration display This is the standard iOS behavior for any app streaming live audio (Apple Podcasts, Spotify, RadioApp, etc.) ## Actual behavior Lock screen shows a scrubber with no duration (stuck at 0 or broken) No LIVE indicator is shown There is no API in expo-audio to signal to iOS that the stream is live ## Requested API Add an isLiveStream boolean field to updateLockScreenMetadata (or equivalent): ```ts AudioPlayer.updateLockScreenMetadata({ title: "Station Name", artist: "Live Radio", isLiveStream: true, // new field }); On the native iOS side this should map to: ```swift nowPlayingInfo[MPNowPlayingInfoPropertyIsLiveStream] = true // Also clear duration and elapsed time for correctness: nowPlayingInfo.removeValue(forKey: MPMediaItemPropertyPlaybackDuration) nowPlayingInfo.removeValue(forKey: MPNowPlayingInfoPropertyElapsedPlaybackTime) MPNowPlayingInfoCenter.default().nowPlayingInfo = nowPlayingInfo ## Workaround There is currently no workaround within expo-audio . Achieving this requires either a native module or dropping down to react-native-track-player which supports isLiveStream out of the box. ## References Apple docs: https://developer.apple.com/documentation/mediaplayer/mpnowplayinginfopropertyislivestream react-native-track-player implementation: https://rntp.dev/docs/api/objects/track#islivestream Similar request in expo-av : expo/expo#12606

https://github.com/react-native-community/react-native-text-input-mask

i'd like to be able to list the build local mode in the eas-cli to be able to bulk delete them

Hello there, As expo-file-system doesn't support web yet I had to come up with a solution for our file storage needs and thought it may be worth sharing here as a starting point to review web support and get an idea on how it could be implemented. In the gist you can find the implementation of our FileSystemUtils, once for native (using expo-file-system) and once for web (using OPFS api) together with the interface contract to keep the method signatures and return types aligned/enforced. With only a few line changes it would even be possible to add Web Worker Thread support without having to change ANY calling code :-). Also blob uri handling and cleanup is also included (through a withFileUrl function + useFileUrl hook) Edit; I'll soon update the gist to include the web worker approach with sync access handle so that safari 18 is also supported. https://gist.github.com/creambyemute/31abd6311c7dab8d721355c4f2d6a8c2