Expo or Native iOS? How We Choose Between Expo and Swift

Expo or native iOS comes down to two questions: do you need Android, and is there a React web app to share code with? If both are yes, pick Expo. If the product is iOS-only for good, or built around Apple-only features, pick Swift. Three of our four mobile products are Expo; one is native SwiftUI.

TL;DR: Expo is our default: one team ships iOS and Android, shares code with a React web app, and still writes Swift or Kotlin through the Expo Modules API when needed. We choose SwiftUI when the app is iOS-only with no web code to share, as with Pullsy. Expo ships three SDKs a year, so budget for upgrades.

This isn't a general native-versus-cross-platform essay. That's on our native vs cross-platform page. This is the decision as it played out on four real apps, and the questions that would move the next one either way.

What are our four mobile products built with?

Three Expo apps and one SwiftUI app. The Expo three share a shape: a Next.js and React web app, one backend serving both, and a mobile app that must exist on both stores. The SwiftUI app has no Android version and no React code to share with.

Product	Mobile stack	Why that stack
NoteTube	Expo / React Native, iOS and Android	The web app is Next.js; the study tools exist on web, mobile, an extension, and an MCP server
GymFast	Expo / React Native, iOS and Android	Three apps (staff, member, trainer) on one token-authenticated API shared with a web dashboard
Kraftr	Expo / React Native, iOS and Android	A companion to the web studio for AI catalog imagery
Pullsy	Native SwiftUI, iOS 17+	iOS-only client; the other clients are a web app and a REST API

The pattern in the table is the whole argument, really. Where there's a React web app and two stores, Expo won. Where there was one store and nothing to share, Swift did.

Why is Expo our default?

Because one small team can cover both stores and the web. A React Native app written with Expo runs on iOS and Android from one codebase, and when the web app is also React, the same people can read and change all of it. For a small team, that matters more than any benchmark.

GymFast is the clearest case. It ships three apps (staff, member, and trainer) on iOS and Android, all on one token-authenticated mobile API shared with the web dashboard. Per-gym brand colors theme the dashboard and every app from one setting. Six native apps for that would be a different company, not a different stack choice.

Three more reasons, each one backed by how Expo works today:

Native code is still on the table. A development build is your own version of Expo Go and can use any native library and change any native configuration (Expo docs). Config plugins change the native project during prebuild, beyond what app config alone can do (Expo docs). The Expo Modules API lets you write your own modules in Swift and Kotlin (Expo docs).

Fixes can skip the queue. EAS Update ships JavaScript changes over the air to builds whose runtime version matches, because an update has to be compatible with the native code already in the build (Expo docs). Native changes still go through the stores. Our release process for that is in a safe Expo OTA update process.

Small details get written once. GymFast saves an in-progress workout on the device, so a dropped connection in the gym doesn't lose a session. Writing that once for both platforms is the point. How it works is in workout logging that survives bad signal.

When do we write Swift instead?

When the app is iOS-only for good and there's no web code to share. That's Pullsy. Its iOS app is native SwiftUI on iOS 17 and later, with push notifications when an account's numbers change. Its other clients are a web app and a REST API, so a cross-platform layer would have bought it nothing.

Four questions push a new app toward native Swift:

1. Is it iOS-only for good? With no Android plan and no shared web logic, cross-platform saves less.
2. Is the product built on Apple features? Widgets, Live Activities, deep HealthKit use, watch apps, or heavy background work are usually more direct in Swift, even though they're reachable from Expo through native modules.
3. Does it need the most native feel possible? SwiftUI gives you Apple's own components with no translation layer.
4. Will a Swift developer own it? A native app nobody can maintain is worse than a cross-platform one.

If the answers are mixed, we don't pick a side. The usual answer is Expo with one small native module for the feature that needs it. That keeps the team on one codebase and puts Swift exactly where it earns its place.

What each choice costs you

Neither route is free. Expo puts a JavaScript layer between your code and the platform and ties you to an SDK upgrade cycle. Swift means a second codebase the moment Android shows up, and no sharing with a React web app. The table is the honest version.

	Expo	Native Swift
Upgrades	New Expo SDK versions are released three times a year (Expo docs), and libraries have to keep up	Yearly iOS and Xcode releases
Performance care	Heavy animations and long lists need memoized rows, virtualized lists, and work off the JS thread	Mostly handled by the platform
Third-party native libraries	Some lag behind new OS releases	Apple's frameworks are available on day one
Android	Same codebase	A second app, team, and release process
Shipping fixes	JavaScript fixes over the air; native changes through review	Every fix through App Store review

Budget for the upgrade cycle from day one. Three SDK releases a year means an Expo app that skips a year falls a long way behind, and catching up then is a project, not a chore.

Which questions should decide Expo or native iOS for your app?

Five, in this order. They're deliberately about your business rather than the technology, because the technology question is mostly settled: both stacks can ship a good app. What differs is how many people, codebases, and releases it takes.

1. Do you need Android in the first year?
2. Is there a web app, and is it React?
3. Which device features does the product depend on, and are any Apple-only?
4. Who will maintain the app in two years?
5. How often will you need to ship fixes?

If the answers run yes, yes, none, a web-leaning team, and often, Expo is the safer bet. If they run no, no, several, an iOS developer, and rarely, Swift is fine. Most real answers are somewhere in between, which is why the mixed case above matters.

The store side barely changes

Not much. Both need developer accounts in your company's name, screenshots, privacy details, and review. With Expo, EAS Submit uploads to both stores from the command line. With Swift, Xcode and App Store Connect do it for iOS. The review rules are identical either way, and the usual traps are in common App Store rejections and their fixes.

FAQ

Is Expo ready for production apps on both stores?

Yes. NoteTube, GymFast, and Kraftr all run on Expo in production on iOS and Android. The prototype reputation dates from before development builds and config plugins, when you couldn't add your own native code. Today a development build can include any native library, so the old ceiling is gone.

Can an Expo app share code with a Next.js web app?

Yes, and that's the main reason we choose it. Types, validation schemas, API clients, and business rules can live in shared packages that both the web and mobile apps import. Screens usually stay separate, because good mobile and web layouts differ, but the logic underneath doesn't need to.

Can we start in Expo and move one screen to native later?

Yes. A native module or native view built with the Expo Modules API can replace a single screen or component without rewriting the app. That's the usual path when one feature, such as a widget or a camera pipeline, outgrows what JavaScript handles comfortably while the rest of the app stays in React Native.

Should a SwiftUI app move to Expo when we add Android?

Not automatically. If the iOS app is large and working, building a separate Android app or moving only new features may cost less than a rewrite. Compare the size of the existing app with what you'd share across platforms, and decide on the numbers rather than on the framework.

Building a mobile app and stuck between Expo and Swift? See how we work with Expo and our iOS app development service, then book a 30-minute call to talk it through.