Building an app for iPhone and Android forces a structural technical choice: write two native apps (Swift for iOS, Kotlin for Android) or a single cross-platform codebase with Flutter or React Native. There is no universal right answer, but there are good criteria. Here is how to choose, without dogma.
The three main approaches
Native: Swift and Kotlin
Each platform has its own language and tools: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. Native development gives immediate, complete access to every system feature, the best possible performance and seamless fit with each platform’s conventions. The trade-off: you build and maintain two apps, so twice as much code for the same features.
Flutter
Created by Google, Flutter uses the Dart language and draws the interface itself with its own rendering engine. One codebase produces the iOS and Android apps (and web and desktop if needed). Strengths: a pixel-identical interface across platforms, smooth animations, high productivity. Limits: a less widespread language than JavaScript, and an appearance that does not automatically adopt each system’s native components (often an advantage for a strong brand).
React Native
Backed by Meta, React Native uses JavaScript or TypeScript and the React model, the most widely used web library. The interface relies on each platform’s native components. Strengths: a huge ecosystem, the ability to share code and skills with a React web app, a native look. Limits: performance can be trickier on heavily animated interfaces, and some features depend more on third-party libraries.
The comparison
| Criterion | Native (Swift / Kotlin) | Flutter | React Native |
|---|---|---|---|
| Codebases | Two | One | One |
| Language | Swift, Kotlin | Dart | JavaScript / TypeScript |
| Performance | Maximum | Very good | Good to very good |
| Interface rendering | Native components | Own engine, identical everywhere | Native components |
| Access to device features | Complete, immediate | Very broad, via plugins | Very broad, via modules |
| Sharing with the web | Low | Possible (Flutter web) | Strong (with React) |
| Maintenance cost | Higher | Contained | Contained |
The criteria that should drive your choice
1. What the app does
A business app — data entry, look-ups, forms, photos, signatures, sync — is ideal ground for cross-platform development: most of the work is shared between the two systems. An app that leans heavily on the hardware (real-time video processing, advanced augmented reality, deep integration with a watch or connected device) may justify native.
2. What already exists
Already have a React web app? React Native lets you share skills and even some logic. Starting from scratch with a strong visual identity? Flutter guarantees identical rendering everywhere. Already maintaining two good native apps? Rewriting them only makes sense if maintaining them has become a burden.
3. Budget and timescale
A single codebase significantly cuts development and maintenance time compared with two native apps. That is often the deciding argument for a first version, and then over the app’s lifetime.
4. Working offline
Many business apps must work without a connection — on a building site, on the road, in a building with poor coverage — and sync when back online. All three approaches can do it, but it has to be designed into the architecture: local database, conflict handling, resuming uploads.
5. Longevity and skills
Flutter and React Native are backed by very large companies and used by many apps in production. The most practical criterion is the availability of skills to maintain the app over time: favour a technology your developer genuinely masters, and for which you could find other developers if needed.
And Kotlin Multiplatform?
A fourth route is gaining ground: Kotlin Multiplatform, which shares business logic (calculations, rules, data access) between iOS and Android while keeping a native interface on each — or sharing that too with Compose Multiplatform. It appeals mostly to teams already expert in Kotlin, or to existing native apps that want to reduce duplication without a full rewrite. For a new project with nothing to build on, Flutter and React Native are usually simpler to put in place.
What about a progressive web app (PWA)?
A PWA is a website that behaves like an app: installable on the home screen, usable offline to a degree, with no app store involved. It suits a simple internal tool or occasional use. Its limits: more restricted access to device features, especially on iPhone, and no presence in the stores. For a management tool used both at the office and in the field, a responsive web application can also be the best first step.
Beyond technology: what makes a good app
The framework is only part of success. Just as important are:
- the user journey, designed and tested with the real people who will use the app;
- the back end: database, authentication, APIs and access rights, often more complex than the app itself;
- security: encrypted storage of sensitive data on the phone, protected exchanges, controlled sessions;
- publishing: Apple and Google developer accounts, store review rules, store listings, privacy policy;
- maintenance: each new version of iOS and Android calls for updates, to be planned from the outset.
Questions to settle before choosing
Before comparing frameworks, a few questions about the project itself usually narrow the choice quickly:
- Who will use the app, on which devices, and how often?
- Must it work offline, and for how long?
- Which device features does it need: camera, location, notifications, Bluetooth, biometrics?
- Does it need to talk to existing systems — an ERP, a CRM, a booking engine?
- Is there already a web application whose code or skills could be shared?
- Who will maintain the app in three years’ time?
The answers matter more than any benchmark: they describe the app you actually need.
Our view
For most business and consumer apps, we recommend Flutter: one codebase, a polished interface that looks the same everywhere, excellent performance. We choose React Native when there is strong synergy with an existing React web app, and native when hardware use demands it. The choice is always made after understanding the use, never before. That is how we approach mobile app development.
Frequently asked questions
Is a Flutter app slower than a native one?
For the vast majority of uses, the difference is imperceptible. It only shows in very intensive processing, where native keeps the edge.
Can we switch from React Native to Flutter, or vice versa, later?
It is possible, but it means rewriting the interface. The back end can be reused as is if it was designed independently — which we always recommend.
Do we have to publish in both stores?
Not necessarily: an internal app can be distributed through channels reserved for businesses. For a public app, though, being on the App Store and Google Play is the norm.
How long does it take to build a mobile app?
It depends on the scope. A first version focused on the essential features is usually measured in weeks rather than months, after which the app grows through successive releases.
The Step By Step studio in Ajaccio, Corsica, designs and builds iPhone and Android apps. Tell us about your project.