Let’s break it down.

Before comparing the packages, you need to understand what’s happening under the hood on iOS. Apple ships two distinct speech frameworks, SFSpeechRecognizer and SFSpeechAnalyzer. What are they?

SFSpeechRecognizer: the classic, supported in most versions

SFSpeechRecognizer has been around since iOS 10. It’s the same engine that powers Siri dictation. By default it sends audio to Apple’s servers for transcription, though an on-device mode was added in iOS 13. It supports both live microphone streaming and file-based recognition, and returns a rolling “best guess” transcript that gets revised as the user keeps speaking.

SFSpeechAnalyzer: the new one

SFSpeechAnalyzer is a newer, higher-level API introduced in iOS 17. It’s Apple’s modern take on speech analysis and was designed for more structured, analytics-focused use cases. It offers better integration with the system and can return richer metadata alongside the transcription but it comes with stricter OS requirements.

Now let’s talk about the expo packages.

expo-speech-recognition

It wraps SFSpeechRecognizer on iOS and uses the SpeechRecognition Web API on Android (via the android.speech.SpeechRecognizer class) and on Web. Platform support:

• iOS: iOS 13+ recommended for on-device mode

• Android: Requires Google app / Speech services

• Web: Chromium-based browsers only

How it works

You get a streaming experience where partial results come in as the user speaks. The API design closely mirrors the browser’s SpeechRecognition interface, so if you’ve worked with Web Speech API before, this will feel familiar.

Code example (simplified):

import { useSpeechRecognitionEvent, ExpoSpeechRecognitionModule } from "expo-speech-recognition";

ExpoSpeechRecognitionModule.start({ lang: "en-US", interimResults: true });

useSpeechRecognitionEvent("result", (event) => {
  console.log(event.results[0]?.transcript); // live partial results
});

Result quality

Decent. On iOS, when Apple’s cloud is involved, accuracy is solid for common vocabulary. On Android, quality heavily depends on the device and whether Google’s speech service is up to date, which can vary noticeably across manufacturers. Web support is Chromium-only, so Firefox and Safari users are out of luck.

expo-speech-transcriber

It wraps SFSpeechAnalyzer, so it’s only available for iOS 17+. This is the biggest trade off; if your app needs to run on Android, web, or iOS below iOS 17, this package won't work.

How it works

SFSpeechAnalyzer takes a more structured approach. Rather than giving you a raw rolling transcript, it returns segmented results with higher confidence metadata. The API is cleaner and the results tend to be more stable, less “jumping around” while the user speaks.

Code example (simplified):

import * as SpeechTranscriber from "expo-speech-transcriber";

// Use the hook for realtime updates
const { text, isFinal, error, isRecording } =
  SpeechTranscriber.useRealTimeTranscription();

// Start transcription
await SpeechTranscriber.recordRealTimeAndTranscribe();

// Stop when done
SpeechTranscriber.stopListening();

Result quality

Noticeably better on iOS 17+ devices. The transcription is more accurate out of the box, punctuation handling is improved, and the metadata you get alongside the transcript is richer. If your entire user base is on modern iPhones, this is the better experience.

Which one should you to use?

• Use expo-speech-recognition if your app targets Android, Web, and iOS versions below 17. In short, use this when you want the largest possible device coverage. The trade-off could be quality of the result, but it’s something you will need to test based on your use case.

• Use expo-speech-transcriber if your app is iOS-only, only need to support iOS 17+, and you want to optimize for better transcription result. This can happen if you're building an app for enterprise iPhone users on managed devices, which you have some knowledge or even control on which version the devices are using.

As of today (March 2026), both packages are actively maintained and easy to set up with Expo managed workflow. The “right” answer almost always comes down to your platform requirements first, then the accuracy. Hope it helps!

1. Local development (simulator, hot reload)

Command: bun ios or bun android

This is what we use for day-to-day development and the simplest to get up and running. The command will start expo dev server, open the simulator, install the app if it’s not installed, and finally opens the app.

2. Development build (device, hot reload, IPA/APK file)

Command: bun build:ios or bun build:android

Sometimes there are features that only work in real device, like notifications. To test the feature, we can run the app in real device while still connecting to Expo server that runs on our machine. The app will still have hot reload, and we can develop the app like usual. To be clear, even though you’ll have IPA/APK file from this, you can’t share it to other users (e.g. internal testers). The app will not run, as it needs to connect to your local Expo server.

3. Preview build (device, no hot reload, for pre-release or QA, IPA/APK file)

Command: bun build:ios:preview or bun build:android:preview

When you’re done with a feature development, you can create a production-like build that you install in your device (or internal testers’ devices). It doesn’t depend on Expo server, the app can use your production endpoints, and you don’t have to wait for approval from App Store or Play Store. Just run the build to create the IPA/APK file, share and download it to your device, then install.

With this build, it’s good to add some indicator, like in the name or the app icon. For example, if your app name is “My App”, then you want it to show as “My App (preview)” for the preview build. This way, the preview and production app can live side by side in your device. If you’re curious on how to do this, check the Expo documentation for “App Variants”.

4. Production build (device, no hot reload, for release or store submission, IPA/AAB file)

Command: bun build:ios:prod or bun build:android:prod

This is the release build that you can distribute to users. It should be nearly identical with the preview build (e.g. except for the app name suffix). Which means, you can be confident enough to run the build command for this and submit to app store, as long as you have tested the preview build. From here, the next step is to submit the app! With eas, you can run eas submit and follow the steps.

—

That’s it! Those are the 4 different builds from development to distribution. It’s not definitive and you can tweak your eas.json and package.json file to customize.

Bonus: The script also have build:ios:prod-eas and build:android:prod-eas. You can use it to run the build in eas instead of locally.

P.S: for reference, here’s my eas.json where I define the different build profiles.

Let’s create an image first. I’ll use Gemini:

Now let’s remove the background using different tools.

1. Photoroom Background Remover. Web based, free (no log in), very good result (smooth edges, text not removed).

2. macOS “Remove Background” (built-in). Local, available by right-clicking an image, then “Quick Actions”, then “Remove Background”. It’s quick and convenient but very bad result (rough edges, text removed).

3. rembg: open source, run from command line, can use different models. This is where it gets interesting. With the default model, the result is not desirable:

But by specifying different model bria-rmbg), the result can be as good as Photoroom:

For me, the result from rembg is sufficient for my workflow and since it runs locally, I can create custom Quick Actions using macOS Automator.

Pick an image, right click, rembg!

It can be slower than Photoroom (took ~20 seconds in my MacbookAir M4, 24GB) but that’s not a pain for me because I can leave it running in the background.

You are building one app but in reality, you’ll interact with 3 different “kind” of your app. Each kind has different purpose, from local development to production. To understand the difference, let’s see it from multiple angles: supports hot reload, config, and build output. We’ll use package.json and eas.json from React Native Ignite boilerplate for reference.

1. Development: supports hot reload, uses development config (i.e. connects to your local endpoints), and has no build output. This is what you get when running expo run:ios or expo run:android.
   Use case: local development.
   Alternatively, if you need to test the app in a real device, you can run the build:ios:device or build:android:device script which produces IPA/APK file that you can install in your device.
   Use case: testing the app in real device, with development config and hot reload enabled.

Some features like push notification, camera, are not available in simulator and can only be tested in real devices. Hence the need for “development” build above.

3. Preview: no hot reload, uses production config (i.e. connects to your production endpoints), creates IPA/APK file. It’s similar like development app above except that it doesn’t need to connect to Expo (hence there’s no hot reload support). Command: build:ios:preview or build:android:preview.
   Use case: QA before release (e.g. install in multiple testers’ devices)

4. Production: no hot reload, uses production config, creates IPA/APK file. This is the one that you use for the app store submission. Command: build:ios:prod or build:android:prod.
   Use case: submission to App Store or Play Store

When the app supports hot reload, it means it has to connect to Expo server in the same network. Which also means that you can’t use it for external testers.

With this knowledge, we can enhance our development workflow by customizing the app (e.g. the app name) based on the kind. This strategy is referred to as “app variants” in Expo (docs). Consider this snippet in Expo config (app.config.ts):

The idea is to customize the app name, e.g. by adding suffix, based on the APP_VARIANT environment variable. This way, we can install 3 different apps in simulator or real devices, for example:

• “My App”: production app (e.g. downloaded from app store)

• “My App (dev)”: app for local development

• “My App (preview)”: app for testers (production build, connects to production endpoints, downloaded from secret link not from app store)

That’s it! Honestly, it was pretty overwhelming when I first try to figure this out. But writing this out has helped me understand it better.

You want to authenticate the users before using the core functionality, so you put a login screen in front. You then realised that you want to collect few extra info from the users to understand them better. Things like how they know about your app, their display name, etc. This info should be entered once, ideally right after they signed up.

Then comes the actual app screens like the home screen, settings, etc. Seems like the steps to the core functionality are long but they’re necessary. Dropping the users right into the log in screen and then to the home screen will not work optimally because they aren’t primed to understand what value the app gives. So here I’m sharing a flow that I think is versatile enough to be applicable for most apps.

The flow:

1. User opens the app. What the user sees about your app so far: the app icon and app name.

2. App shows the splash screen. From technical perspective, it’s a good place to wait for app initiation process (few seconds). From user’s perspective, it’s a good step to prime the user for the app’s experience.

3. App shows the onboarding screen. This is where you explain the app’s purpose in few steps. User will slides through the onboarding screens. Each screen can contain an image or animation, a title, and description to explain what users can get from the app. At the end of the onboarding screen, users can press the “Get Started” button which brings the to the next step.

4. The login screen (optional) and onboarding form. You can remove the login screen if your app doesn’t need authentication. The onboarding form is where you collect extra info like user’s display name, how they know about your app, referral code, etc.

5. Once the onboarding form is filled, user can navigate to the home screen. This is where they get the main value from the app. Be it a recipe app, marketplace, note taker, etc. A home screen can have a common structure (layout) of a screen with bottom tab bar. The bottom tabs consist of: home, some other main pages, then settings.

That’s the flow! It’s quite generic and can be applied in most apps. The goal is to prepare the users as best as possible so they know how to get the value (the aha! moment) by the time they see the home screen.

Demo

Here’s a preview of the flow in a demo app I created:

If you’re curious, here are the tools I use to create the app:

• Ignite boilerplate: an open source Expo boilerplate from InfiniteRed. It provides dark mode, I18n including RTL, and more.

• react-native-onboarding-swiper for the onboarding screens

I’ll write more liberally here. Software engineering, reviews on products I bought, or recent news where I want to exercise my opinion. I’ll still maintain my other blog, wzulfikar.com, for essays and reflections.

Now, I’ll write this for myself: a perfect task is a task completed.

Nothing can be perfect if it’s never done. Don’t fuss over small details. Substance over form. Define finish line, polish post completion.

So much happened over a year; buildings being built, papers published, companies went public, yet I’ve done very small.

Don’t waste time. Stay focused. Prioritize.