Native vs React Native vs Flutter: which should your first app be built in?

If your first app needs to be on both iPhone and Android and its main job is forms, lists, accounts and payments, build it cross-platform: React Native with Expo or Flutter. Choose native Swift and SwiftUI when the app is iPhone-only at launch, or when its core feature depends on Apple frameworks such as the camera pipeline, widgets or HealthKit. The language matters less than who will maintain the code after launch, so pick the stack your developer ships in every week.

The short version

Question	Native (Swift / Kotlin)	React Native + Expo	Flutter
One codebase for iPhone and Android	No, two apps	Yes	Yes
Language	Swift, Kotlin	TypeScript / JavaScript	Dart
Best fit	iPhone-first apps, deep OS features	Apps with web-style UI, teams that also do web	Apps with a highly custom visual UI
New OS features	Available first	Through libraries or a small native module	Through plugins or a small native module
Hiring pool	Separate iOS and Android skills	Large, overlaps with web developers	Smaller, Dart-specific

What each option actually is

Native. Apple's own toolkit is Swift with SwiftUI, which Apple describes as a way to build apps across all Apple platforms with one set of tools and APIs (Apple, SwiftUI). Android's equivalent is Kotlin. If you want both stores natively, you are paying for two apps.

React Native with Expo. React Native lets you write the app in TypeScript and render real native components. The React Native docs now recommend starting new apps with a framework and name Expo, which adds routing, ready libraries and plugins that change native code without you managing native project files (React Native docs).

Flutter. Google's framework describes itself as open source and able to build natively compiled apps for mobile, web and desktop from a single codebase (flutter.dev). It draws its own UI, so screens look the same on both platforms.

Capacitor. A fourth option you will hear about: a native runtime for web apps (Capacitor docs). It suits games and apps whose UI is already a web app.

How popular they are

Popularity is a proxy for how easy it will be to find someone to maintain the code later. In the Stack Overflow Developer Survey 2024 (45,841 responses), Flutter was used by 9.4 percent of respondents, React Native by 8.4 percent and SwiftUI by 4.3 percent; among professional developers the gap between Flutter (9.4) and React Native (9.0) was almost nothing (Stack Overflow 2024). The 2025 survey did not chart these frameworks, so 2024 is the latest comparable data (Stack Overflow 2025).

The takeaway: both cross-platform options have a large enough community that you will not be stranded.

Does cross-platform save money?

Usually, yes, because one codebase replaces two. One vendor puts the saving at roughly 30 to 40 percent of client engineering cost versus two native apps (Idealogic, updated October 2026). Treat that as a vendor estimate: the saving shrinks when the app needs a lot of platform-specific work, and it disappears if you only ship on iPhone.

A decision checklist

Answer these in order. The first "yes" usually decides it.

1. Is the app iPhone-only for the first year? Go native Swift and SwiftUI. No cross-platform layer, direct access to every Apple API, and StoreKit 2 for purchases.
2. Is the core feature an OS capability? Multi-camera recording, Live Activities, complex widgets, background audio or HealthKit-heavy logic. Native, or cross-platform with a planned native module.
3. Do you need both stores at launch with a normal business UI? React Native with Expo or Flutter.
4. Will the same developer also build your web dashboard or SaaS? React Native, because the TypeScript, data models and much of the logic are shared with a React web app.
5. Is it a 2D or 3D game or a kids' play app? A web game engine inside Capacitor, or a game engine such as Unity. Not a business UI framework.
6. Do you already have a team or agency on one stack? Use theirs. Switching later costs more than any framework difference.

Questions to ask a developer before you agree on a stack

• Which of your live apps are built in this stack, and can I install them?
• How do you handle in-app purchases and subscriptions on both stores?
• What happens when the app needs a native feature your framework does not cover?
• Who updates the app for each new iOS and Android release, and how?
• Will the code and build setup run on someone else's machine if you stop working with me?

A developer who answers with links to store listings is giving you better evidence than a framework comparison chart. See also questions to ask before hiring an app developer.

What ODEL uses, and why

ODEL ships in three stacks and uses its own project templates for each:

• React Native with Expo for business and lifestyle apps on both stores. BidCraft, an estimate and invoice app for contractors, runs on Expo with a local SQLite database, PDF export and StoreKit purchases. DishBook runs on Expo on iPhone and Android with a Supabase backend, a Node.js API and an admin panel. Unvay uses Expo with home screen widgets on both platforms.
• Capacitor for apps whose interface is a web app and for games: Focus Timer, DREA and Appalize Shots.
• Swift and SwiftUI for iPhone-only apps that lean on Apple frameworks, with StoreKit 2 and no third-party SDKs by default.

ODEL does not build in Flutter. If you already have a Flutter codebase, or you want Flutter specifically, a Flutter specialist is the better hire.

When ODEL fits, and when it does not

ODEL fits if you want one developer to pick the stack with you, build the app and run the store launch: see cross-platform app development, iOS app development and Android app development.

Look elsewhere if:

• you need a Flutter or Kotlin Multiplatform codebase,
• you need a large in-house team or on-site support,
• the app is a regulated system that requires a certified vendor.

If you are still deciding what to build, start with validating the idea. If you know what you need, send a short brief and ODEL will suggest a stack in the discovery call.