For most business apps, building iOS and Android from one codebase with React Native or Flutter is enough. Native development, meaning separate apps in Swift and Kotlin, pays off when the app depends heavily on platform features or when you can staff a dedicated team for each platform. Between React Native and Flutter, the choice usually comes down to the language your team knows and how much code you want to share with the web.
How the three approaches work
React Native lets you write the app in JavaScript or TypeScript using React’s component model. At runtime it creates the corresponding iOS and Android views for each component, so a <Text> becomes a UITextView on iOS and a TextView on Android (React Native docs). The React Native team recommends starting new projects with a framework such as Expo (reactnative.dev).
Flutter is written in Dart and, instead of using the platform’s UI controls, draws its own implementation of each one. On mobile, rendering is handled by the Impeller engine, and release builds are compiled directly to machine code (Flutter architectural overview).
Native development means writing the iOS app in Swift with SwiftUI and the Android app in Kotlin with Jetpack Compose, as two separate projects. Google describes Compose as Android’s recommended modern toolkit for building native UI.
| Aspect | React Native | Flutter | Native |
|---|---|---|---|
| Language | JavaScript / TypeScript | Dart | Swift (iOS), Kotlin (Android) |
| UI | The platform’s own components | Components Flutter draws itself | The platform’s own components |
| Codebases | One | One | One per platform |
| Platform APIs | Existing library or a native module | Existing package or a platform channel | Direct |
| Sharing with the web | React skills and business logic | Flutter web exists, not recommended for content sites | None |
Performance, UI and platform APIs
Performance and UI
The React Native docs state that because its components are backed by the same views as Android and iOS, React Native apps look, feel and perform like other apps. Flutter draws the same UI on every platform and ships Cupertino (iOS-style) and Material widgets (Flutter FAQ). One consequence: since Flutter draws its own controls, visual changes a platform makes to its native controls do not automatically appear in your app.
For business apps built around lists, forms, maps and payments, all three approaches can deliver a smooth experience. When such apps feel slow, the cause is more often oversized images, unnecessary network calls and needless re-renders than the framework itself. If you need heavy animation, game-like graphics or real-time camera or audio processing, we suggest measuring with a small prototype before you commit.
Access to platform APIs
All three can reach every capability of the phone; the difference is who writes the code that bridges to it. In React Native, if the platform API you need isn’t provided by React Native or an existing library, you write the integration yourself as a Turbo Native Module. In Flutter the same job is done with platform channels or the Pigeon package. Either way, the platform side is written in Kotlin/Java and Swift/Objective-C.
Some features are native by nature. On iOS, home screen widgets and Live Activities are built with WidgetKit using SwiftUI views (Apple), so even in a cross-platform app that part is written in Swift. Apple and Google ship new capabilities through their own SDKs; on the React Native or Flutter side you either wait for a library to add support or write the module yourself.
We usually build iOS and Android from one codebase with React Native and add platform-specific modules where existing libraries fall short.
Team skills and code sharing with the web
Choosing a technology is really choosing a team. React Native brings the React programming model to Android and iOS (reactnative.dev), so a web team that knows React and TypeScript keeps the same language, component thinking and package manager. Flutter needs a team that knows Dart or is ready to learn it; the Flutter framework itself is written in Dart (Flutter FAQ). Native needs two specialisms: Swift for iOS and Kotlin for Android. Google recommends starting new Android apps with Kotlin and designs new tools such as Compose with Kotlin users in mind (Android Developers).
If you already have an admin panel or customer site built with React or Next.js, React Native lets you share TypeScript types, the API client, validation rules and business logic. UI components don’t carry over directly, because React Native uses its own primitives such as View and Text rather than HTML. The community project React Native Web runs those components in the browser, and Expo aims to produce Android, iOS and web apps from a single project.
Flutter can also target the web, but Flutter’s own documentation says Flutter web suits app-centric experiences such as PWAs and single-page apps, is not suitable for text-rich static sites like blogs, and produces output that doesn’t align with what search engines need for indexing (Flutter web FAQ). If you have pages that must rank in search, plan them separately.
Ecosystem, app size and long-term maintenance
Ecosystem. React Native draws on npm packages and community-built native components (React Native docs). Flutter packages are published on pub.dev. Native apps use Apple’s and Google’s own libraries directly. Whichever route you choose, check a library’s last release date, its open issues and whether it supports the current framework version before adding it. Every dependency is something you will have to update later.
App size. According to Flutter’s documentation, the engine adds a small baseline of a few megabytes compressed, and size is largely determined by assets, fonts and third-party packages (Flutter FAQ). React Native uses the Hermes engine by default, which the docs say gives many apps a smaller size than JavaScriptCore (Hermes). A native app carries no extra framework engine. Either way, measure the real download size from Play Console and App Store Connect reports rather than from local build output (Flutter).
Maintenance and hiring. Store requirements affect all three. On Google Play, new apps and updates must target Android 16 (API level 36) from August 31, 2026; apps uploaded to the App Store since April 28, 2026 must be built with Xcode 26 and the iOS 26 SDK. Cross-platform projects add framework upgrades and library compatibility on top; native projects do the same work in two codebases. Hiring follows the same pattern: React Native draws on JavaScript/TypeScript skills shared with the web, Flutter needs Dart experience, and native needs two separate specialist profiles.
When each option makes sense
React Native makes sense if:
- Your team knows React and TypeScript, or your web side is built with React or Next.js.
- You are building a business app with several roles (customer, business, courier) that is mostly forms, lists, maps and payments.
- You want the UI to use each platform’s own components.
Flutter makes sense if:
- You want a custom, animation-rich branded UI that looks identical on every platform.
- Your team knows Dart or is ready to learn it.
- You also plan desktop versions; Flutter supports macOS, Windows and Linux (Flutter FAQ).
Native makes sense if:
- The app’s value depends on deep platform integration: widgets, watch apps, background work, heavy camera or sensor use.
- You only target one platform.
- You can build separate, long-term iOS and Android teams.
Frequently asked questions
Where does Kotlin Multiplatform fit?
Kotlin Multiplatform is an open-source technology from JetBrains for sharing code across Android, iOS, desktop, web and server. You can build the UI natively with SwiftUI or UIKit, share it with Compose Multiplatform, or mix the two (Kotlin docs). It is a fourth option for teams with strong Android skills that want to keep a native UI on iOS.
Can I add React Native or Flutter to an existing native app?
Yes. React Native supports adding a single screen or user flow to an existing native app, and Flutter can be embedded into existing Android and iOS apps with Add-to-App. That lets you migrate gradually by building new features with the new technology instead of rewriting everything.
Can we switch technologies later?
Yes, but the UI layer is largely rewritten. The backend, API and database can stay the same, so keeping business rules on the server as much as possible makes any future switch easier.
Conclusion
The choice between React Native, Flutter and native is usually decided less by raw performance than by your team’s language, the code you want to share with the web, and how deeply the app must integrate with each platform. We usually go with React Native and one codebase, adding platform-specific modules when needed. For what drives the budget, see our article on mobile app development cost. If you like, we can look at the right approach for your project together: see how we work on our web and mobile app development page.
