Expo vs Flutter: one is a React Native framework, the other is a framework, a language and a renderer.
Expo vs Flutter is a real choice, but not a symmetric one. Take Expo if your team already writes React and TypeScript, wants Android, iOS and web from one codebase, and wants to push fixes between store releases. Take Flutter if you want one toolkit that draws its own interface on phones, web, desktop and embedded devices, and you are willing to write Dart. The asymmetry is in the names. Expo's own getting started page calls Expo a React Native framework, so the engine room of this comparison is React Native against Flutter, and Expo is the layer and the cloud services sitting on top of it.
That matters because the arguments people have here belong to two different levels. Dart against TypeScript, and a self-drawn widget set against the platform's own controls, are React Native questions. File-based routing, Expo Go, development builds, over the air updates, hosted builds and a monthly invoice are Expo questions, and Flutter answers several of them by naming other people's tools in its own documentation. Everything below was read off docs.expo.dev, expo.dev and docs.flutter.dev on 1 October 2026, not off a roundup.
Answer three questions and get a pickThe short version
One is a layer on React Native, the other is the whole stack.
So read the question as two decisions stacked on each other. The first is React Native or Flutter, which settles the language, the way the interface is drawn and the people you can hire. The second only exists on the React Native side: use Expo's framework and its Expo Application Services, or assemble the same jobs yourself. Flutter has no second product to buy, and its own pages hand the equivalent jobs to third parties, Shorebird for code push and Codemagic, Bitrise, Appcircle or fastlane for delivery.
The short answer, then. A React team shipping a phone app with a web twin should take Expo. A team whose target list includes desktop or embedded devices, or that wants one interface drawn identically everywhere, should take Flutter. The cases where that flips are below, along with the things neither project publishes, because guessing at those is how comparison pages end up wrong.
Expo calls itself a React Native framework, in those words
Expo's getting started documentation opens with a sentence worth taking literally: Expo is a React Native framework that makes developing Android and iOS apps easier, and it provides file-based routing, a standard library of native modules and more. The same page says Expo is open source, and that the company also makes Expo Application Services, described as a set of services that complement the framework at each step of development. So Expo is two things behind one name: an open source framework you install, and a paid cloud platform you can use or ignore.
Flutter's own FAQ opens differently. It says Flutter builds applications for mobile on iOS and Android, for the web, for desktop on macOS, Windows and Linux, and for embedded devices, from a single codebase, that it works with existing code, and that it is free and open source. There is no second product behind it and nothing to subscribe to. Google maintains the framework, the widget sets and the engine, and leaves delivery to whatever continuous integration you already run.
That is why the useful version of this comparison puts React Native, rather than Expo, on one side of the scales. If you have not met it, what is react native is the prerequisite reading. React Native's own home page says React primitives render to native platform interface elements, so your buttons are the platform's buttons and they behave the way the rest of the phone behaves. Flutter's architecture page says the opposite on purpose, which is the next section.
Expo documentation, Create a project, on what Expo and Expo Application Services are
What each one draws, and where it runs
Flutter's architectural overview describes what cross-platform frameworks usually do, which is to put an abstraction layer over the native Android and iOS interface libraries, and then says Flutter sets that aside in favour of its own widget set. The Dart code that paints Flutter's visuals compiles to native code and renders through Impeller, which ships inside your application rather than coming from the operating system. Flutter also ships Material Design and Cupertino widget sets, supports Material Design 3, and can embed a real platform view in the widget tree when you need one, such as a map or a web view.
The practical consequence is the thing teams actually feel a year in. On Flutter, what you draw is what every platform shows, so visual parity is free and platform behaviour is your job. On React Native, and so on Expo, a control is the platform's control, so it inherits the platform's behaviour and its updates whether you asked for them or not. Neither is a defect. A strong in-house design system usually prefers Flutter. An app that should feel like it came with the phone usually prefers the other side.
Reach is the clearest gap in the whole comparison, and it is worth checking against your own target list before anything else. Flutter's FAQ lists deployment to iOS, Android, the web, desktop on macOS, Windows and Linux, and embedded devices, and says you can develop on macOS, Windows, Linux or ChromeOS. Expo's documentation is about Android, iOS and the web: its own tutorial is framed as creating a universal Android, iOS and web app, and we found no documented desktop or embedded target anywhere on it. If a Windows build is on the plan, that single line settles the question.
Shipping, updating, and what each one costs
Here the two stop being comparable, because Expo sells the pipeline. Expo's documentation describes EAS Build as a hosted service that builds app binaries for Expo and React Native projects, handles your signing credentials if you let it, integrates with EAS Submit for store submissions, works for native projects whether or not they use Expo, and can also run on your own machine. EAS Update is described as a cloud service that lets a shipped app update its own non-native pieces, meaning JavaScript, styling and images, over the air between store submissions.
Flutter's answer to the first is other people's services, named on its own continuous delivery page: Codemagic, Bitrise and Appcircle as options with Flutter support built in, then fastlane combined with GitHub Actions, GitLab, CircleCI, Travis or Cirrus, plus a section on Xcode Cloud. Its answer to the second is a flat no. Flutter's FAQ states that Flutter does not provide built-in code push functionality and points at Shorebird, a third party, for teams that want it. If weekly fixes that skip the review queue are part of your plan, that is the largest single difference on this page.
Cost follows the same shape. Both frameworks are open source and free to install. Expo Application Services is the part with a price list, and expo.dev/pricing today shows a Free tier at 0 dollars a month with 15 Android and 15 iOS builds and updates for 1,000 monthly active users, Starter at 19 dollars a month, Production at 199 dollars a month, and a custom Enterprise tier, each with additional usage charged on top. Flutter sends no such invoice, which is not the same as being cheaper, because your build minutes still land on somebody's bill. Expo also moves in SDK releases, and each upgrade is a planned job rather than a surprise; we walked one of those cycles through in expo sdk 54.
Three questions
Expo or Flutter for this project
What does your team write today?
Where does it have to run?
What matters most after launch?
Expo
Your answers point at the React Native side: existing React skills, a web target, and fixes that go out between store releases.
When to pick each one, and when it does not matter
Pick Expo if two or more of these are true. Your team writes TypeScript. The same product needs a web version. You want someone else to run builds and submissions. You need to fix a bug for live users this afternoon. The React ecosystem arrives with it, and so does a hiring pool larger than Dart's, which is a staffing fact rather than a technical one but tends to outlast both.
Pick Flutter if the target list reaches past phones and the browser, if you want one widget set and one rendering path on every platform, or if you would rather own the entire delivery pipeline than rent part of it. Flutter's FAQ also covers the questions teams with existing apps ask: Flutter can go inside an existing Android or iOS app through its add to app route, and platform services reach it through plugins on pub.dev, platform channels or Dart interop.
The honest case for not caring: for a phone app with a handful of screens, a list, a form and a sign-in, both will ship it, and the thing that decides the project is not on this page. It is what your team can still maintain next year. If you have not yet settled whether you want one codebase at all instead of two native ones, start a level up at the cross platform choice, then come back here once that is decided.
The five things that actually decide Expo against Flutter
| What decides it | Expo | Flutter | Who it favours |
|---|---|---|---|
| Language and how the interface is drawn | TypeScript or JavaScript on React Native, whose own site says React primitives render to native platform interface elements | Dart, with Flutter's own widget set and the Impeller renderer shipped inside the app, per its architecture page | Existing React teams, against teams who want one identical interface |
| Targets the project documents | Android, iOS and the web; no desktop or embedded target documented | iOS, Android, web, desktop on macOS, Windows and Linux, and embedded devices, per the Flutter FAQ | Flutter, the moment desktop or embedded is on the list |
| Updates between store releases | EAS Update, a cloud service that ships new JavaScript, styling and images over the air | Flutter publishes no built-in code push and names Shorebird, a third party, instead | Expo, for anyone fixing bugs weekly |
| Hosted builds and store submission | EAS Build, a hosted service that also integrates with EAS Submit, and can run on your own machine | No first-party build service; the docs list Codemagic, Bitrise, Appcircle, fastlane and Xcode Cloud | Expo, if nobody on the team wants to own continuous integration |
| What it costs to use | Framework is open source; EAS is priced at 0, 19 and 199 dollars a month plus usage, with a custom Enterprise tier | Free and open source, with no plan to buy; you pay whichever build service you choose | Flutter, if a per-usage platform bill is a problem |
Starting the project either way
Whichever side wins, the first week looks similar: a build running on a real device, navigation, one screen that reads real data, and a decision about where that data lives. On the Expo side you begin in Expo Go, then move to a development build, which Expo's docs describe as your own version of Expo Go where you can use any native library and change any native configuration, and which they recommend once you intend to release to the stores. On Flutter you install the SDK on macOS, Windows, Linux or ChromeOS and run against a simulator or a device from the first commit.
One disclosure, since you are reading this on a builder's site: Newly is an AI app builder that writes React Native and TypeScript projects you own, runs them on cloud iOS and Android simulators, and ships to TestFlight and to Google Play internal testing, which puts it on the React Native side of this split. That is a fact about where we sit, not an argument, and it is not a reason to choose a framework.
What should decide it is duller than any benchmark. Write down the platforms you have to ship to, the language your team writes today, and how often you expect to ship after launch. Those three answers pick a side more reliably than any performance chart, and both projects publish enough documentation that you can check every claim on this page yourself in an afternoon.
Questions people ask about Expo and Flutter
Neither wins on merit alone, because they are different sizes. Expo is a React Native framework plus optional cloud services, and Flutter is a framework, a language and a renderer in one. Expo suits teams who already write React and TypeScript and want Android, iOS and web. Flutter suits teams whose target list includes desktop or embedded devices, or who want one interface drawn identically on every platform.
Build the thin version before the argument gets expensive
Write down the platforms you actually have to ship to, the language your team writes today, and how often you plan to push fixes after launch. Then build a small working version and let it tell you which stack you can live with.
Start building