Feature Requests

expo-doctor currently outputs human-readable text only. There's no Node API and no --json flag, which makes it difficult to consume programmatically in CI scripts without parsing the raw output with fragile string matching. Scripts that want to act on expo-doctor results have to parse ✔/✖ characters from the verbose CLI output and hard-code check names that must match exactly — both of which break silently when the output format or check names change. We currently are running expo-doctor in our CI environment, and we want to fail on anything except dependencies being out of date, so we have to have custom logic in place to parse the output, etc.

expo-audio 's AndroidOutputFormat and AndroidAudioEncoder unions are a strict subset of what the underlying MediaRecorder supports. MediaRecorder.OutputFormat.OGG and MediaRecorder.AudioEncoder.OPUS have been available since API 29 (Android 10, 2019) but are not reachable from JS, even though the rest of the recording pipeline is a straight passthrough to MediaRecorder . Adding them is a ~20 line change: two enum entries plus API 29 guards in AudioRecords.kt , and two entries in Audio.types.ts . Two concrete wins that the current M4A/AAC-only path can't deliver: Crash-safe recordings. M4A is an MP4 container — it requires the muxer to finalise the moov atom on stop() . If the app is killed mid-recording the file is unplayable. OGG is a chunked, self-describing container: every page is independently valid and carries its own CRC. A killed recording remains playable up to the last complete page. This is the main reason we reach for OGG on Android. Opus is dramatically more efficient for voice than AAC. 32 kbps mono Opus is effectively transparent for speech. A 20-minute recording is ~5 MB at the settings we use, versus ~19 MB for the AAC default — useful for memory, storage, and upload cost. Opus also has lower latency and is the default voice codec for every modern browser/WebRTC stack. Both use cases are reachable today if you drop down to writing a native module, but that's a lot of plumbing for two enum entries.

The current setActiveForLockScreen API in expo-audio provides options to control lock screen media controls such as showSeekBackward and showSeekForward, but it does not expose a way to disable scrubbing (dragging the playback progress bar) from the system lock screen media player. However, native media frameworks already support restricting or disabling this behavior. Exposing this capability in Expo would allow developers to have finer control over playback interactions on the lock screen. Proposed enhancement: Add a new option, for example: showScrubbing?: boolean or allowScrubbing?: boolean. Defaulting to true for backward compatibility. Use case: This feature is useful in scenarios where scrubbing should be restricted, for example: Advertisement playback where skipping or seeking must be prevented; Licensed or time-sensitive content where seeking is not allowed; Guided audio experiences (e.g., meditation, educational content) where linear playback is required. Expected behavior: When showScrubbing: false, the system lock screen media interface should not allow the user to drag or change the playback position, while still allowing basic controls like play/pause.

We'd like to record in a streamable format such that the recording is valid if it is interrupted in the middle (like if the app is killed). The variety of AAC formats require stopAndUnloadAsync() to be called in order to produce a valid recording file as far as I can tell. LinearPCM/WAV works but makes very large recordings. Opus offers a smaller file format that supports streaming.

Today, any build that ends up on EAS via a local path is forced to: distribution = Internal profile / runtime / channel = None a "Local" chip on the dashboard This happens because packages/eas-cli/src/commands/upload.ts hardcodes distribution: DistributionType.Internal in createLocalBuildAsync , and neither eas upload nor eas build --local accepts --profile , --channel , --distribution , or --runtime-version flags. Use case: I build my production iOS binary locally (to keep signing under my control, to avoid EAS build minutes, or to iterate faster) and then submit it to App Store Connect with eas submit . I would like the resulting row on expo.dev to accurately reflect that this was a "production" profile build, with the correct channel and runtime, so that: The dashboard gives a truthful audit trail of what went to the store. EAS Update channel resolution works correctly against the build. Teammates can tell production binaries apart from dev or preview builds at a glance. Proposed solution: Add the following flags to eas upload (and surface the same metadata on eas build --local ): --profile <name> Build profile from eas.json to tag the upload with --distribution <type> internal | store --channel <name> EAS Update channel --runtime-version <value> Runtime version (or read it from the binary when possible) Internally, this means: Accepting these flags in the oclif command spec. Resolving the profile via EasJsonAccessor the same way eas build does. Passing the resolved values into LocalBuildMutation.createLocalBuildAsync instead of the current hardcoded DistributionType.Internal . Workarounds today: eas build --local --auto-submit submits the binary to App Store Connect correctly, but the EAS dashboard row is still stamped as "Local / Internal / None / None". eas submit --path ./build.ipa --profile production only tags the submission, not the build row. Neither workaround gives a correct production row on the builds page.

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

Since Android 13 it is possible to prevent only recent screenshots which will only hide the app content in the app switcher, but not prevent the user from taking screenshots https://developer.android.com/reference/android/app/Activity#setRecentsScreenshotEnabled(boolean) . It would be nice, if that would be added to this plugin.

install-expo-modules currently forces package install (expo install, babel-preset-expo) and pod install, which makes it hard to use in CI, monorepos, or setups where dependency installation is already handled externally. It would be helpful to add a few optional flags like --skip-package-install, --skip-pod-install, and --platform ios|android so the command can be used purely for native/config integration when needed. This is a small, non-breaking change—default behavior remains the same, and the implementation is straightforward since Android/iOS steps are already independent and can be gated with simple conditionals. This would make the tool much more flexible without adding complexity for existing users.

This feature exists for ios as attachments when scheduling a local notification, but the option does not exist for Android even though it's been supported for many years natively on Android.