Stack Guide
What to build a mobile app with in 2026
Mobile is the one platform where a bad stack decision is expensive to undo, because app store review sits between you and every fix. The right default gives you one codebase, two platforms, and the ability to ship a JavaScript patch in minutes instead of days.
About 6 min read. Recommendations verified August 2026.
The recommended mobile app stack
One codebase shipping to iOS and Android, with over-the-air updates so a broken build is a five-minute problem rather than a five-day one.
| Layer | Pick | Why |
|---|---|---|
| Framework | Expo SDK 57 | Brings React Native 0.86. Expo is now the default way to use React Native, not an optional wrapper around it. |
| Runtime | New Architecture | Mandatory since SDK 55 and no longer disableable. Hermes v1 became the default engine in SDK 56 with faster startup and lower memory use. |
| Language | TypeScript | Share types with your API and your web app. A wrong prop shape on mobile is a crash a user reports days later, not a red squiggle. |
| Navigation | Expo Router | File-based routing with real deep links and universal links, which matters the moment marketing wants to link into a screen. |
| Server state | TanStack Query | Caching, retries, and offline behaviour handled once. Mobile networks fail constantly, and hand-rolled fetch logic never handles that well. |
| Styling | NativeWind | Tailwind class names compiled to native styles, so web and mobile share one design vocabulary. StyleSheet is the safe fallback. |
| Builds and updates | EAS Build and Update | Cloud builds with no Xcode machine to babysit, and JavaScript-only fixes shipped over the air without a review cycle. |
| Auth | Clerk or Better Auth | Native SDKs with secure token storage, biometric unlock, and Sign in with Apple, which Apple requires if you offer other social logins. |
| In-app purchases | RevenueCat | StoreKit and Play Billing have genuinely hostile edge cases around restores, renewals, and refunds. Do not implement receipt validation yourself. |
| Crash reporting | Sentry | With source maps uploaded per build. Store crash logs are close to useless for a minified JavaScript bundle. |
The verdict
Expo SDK 57 with React Native 0.86, Expo Router, TanStack Query, and EAS for builds and over-the-air updates. Go fully native only when a platform capability, not a preference, forces it.
Why Expo, and why the old objections expired
The historical case against React Native was the bridge: a serialized, asynchronous boundary between JavaScript and native code that made list scrolling and gesture handling feel wrong. That bridge is gone. The New Architecture with Fabric and TurboModules has been mandatory since Expo SDK 55, the legacy path was removed from the React Native codebase entirely, and React Native 0.85 in April 2026 was the release where the new path stopped being the exception and became the assumption.
The second objection was that Expo locked you out of native modules. That has not been true since the config plugin and development build system landed. You can add any native dependency, write your own native code, and still use EAS for cloud builds. Bare React Native without Expo now means opting out of a build service, an update service, and a module ecosystem in exchange for very little.
The feature that actually justifies the choice is over-the-air updates. A JavaScript-level bug in a native app normally means a new binary, an App Store review, and a staged rollout - days, minimum, and users on the broken version until they update. EAS Update ships a corrected bundle in minutes. Over the life of an app that single capability changes how aggressively you can ship, which is worth more than any rendering benchmark.
One thing to plan for: your app needs a backend, and it should be the same backend your web product uses. Do not build a mobile-specific API. Build one versioned HTTP API, because old app versions live on devices for years and you cannot force an upgrade. The backend API guide covers the versioning discipline that makes this survivable.
Credible alternatives and when they win
Native Swift and Kotlin
Wins when the app is the product and it lives on platform APIs: custom camera pipelines, background audio, Bluetooth, ARKit, widgets, watch and TV targets. Also wins when you already employ native engineers. You are paying for two codebases, so the capability had better be central.
Flutter
Wins when you want pixel-identical UI on both platforms and heavy custom animation, since it renders everything itself rather than mapping to native widgets. The cost is Dart: a smaller hiring pool and no code sharing with your web frontend.
Kotlin Multiplatform
Wins for teams with an existing Android codebase who want to share business logic while keeping fully native UI on each platform. The most conservative way to get code reuse without accepting a cross-platform rendering layer.
A progressive web app
Wins for content and tool apps with no store requirement: no review process, no 15 to 30% platform cut, instant updates. Loses on iOS, where push and background execution remain restricted, and on discoverability if users expect to find you in a store.
Decision factors that change the answer
- Native API depth. List the platform capabilities the app genuinely needs. If any of them is central and has no maintained React Native module, that decides it.
- Existing team. A React team ships a good Expo app in weeks and a mediocre Swift app in months. A native team does the reverse. Match the stack to the people you actually have.
- Do you need the store at all. If you are not charging through in-app purchase and users will accept a home screen icon, a PWA skips review, fees, and two release pipelines.
- Offline requirements. An app that must work with no signal needs a local database and a sync strategy designed up front. That is architecture, and no framework choice substitutes for it.
- Release cadence. Weekly shipping strongly favours over-the-air updates. Quarterly releases with a QA gate care much less, which weakens one of Expo's biggest advantages.
Mobile app stack questions, answered
Is React Native still a safe bet in 2026?
Safer than it has ever been. The New Architecture is mandatory from Expo SDK 55 onward and the legacy bridge has been removed from the codebase, so the performance complaints that defined the 2020 debate no longer describe the framework. React Native has also moved to a release model where roughly every second version ships with no user-facing breaking changes.
Should I use Expo or bare React Native?
Expo, essentially always. Config plugins and development builds removed the old limitation on custom native code, so choosing bare now means giving up cloud builds, over-the-air updates, and the module ecosystem in return for almost nothing. If you later need something Expo cannot express, you can eject.
When should I go fully native instead?
When a platform capability is the product: real-time camera processing, background audio or BLE, ARKit, complex widgets, watch and TV targets, or anything with hard frame-budget requirements. Also when you already employ native engineers, because their velocity in Swift or Kotlin beats their velocity in an unfamiliar cross-platform stack.
Do I need a separate backend for a mobile app?
No, and you should not build one. Use the same versioned HTTP API your web product uses. What mobile does add is a hard versioning discipline: old app versions stay installed on devices for years and you cannot force an upgrade, so every endpoint change must be backward compatible or explicitly versioned.
Where to go next
Since the UI layer is React either way, React vs Svelte is worth reading before you commit a web codebase alongside it, and frontend tools covers the shared component story. Set up sign-in from auth tools, crash reporting from monitoring, and keep the TypeScript cheatsheet handy for the shared types.