Compare native, cross-platform and web approaches and explain when each one fits.
Why this choice matters
Before you write a line of mobile code, someone on the team decides how the app will be built. That decision shapes which languages you need, how many codebases you maintain, how fast features ship and how the app feels in the hand. As a mobile developer you will be asked to explain the trade-offs, so it pays to understand them clearly rather than repeat opinions from the internet.
There are three broad options:
- Native: one app per platform, written with the platform's own tools. iOS apps use Swift (older code uses Objective-C) and Apple's SwiftUI or UIKit in Xcode. Android apps use Kotlin (older code uses Java) with Jetpack Compose or Android Views in Android Studio.
- Cross-platform: one codebase that produces apps for both platforms. The two big frameworks are React Native (JavaScript or TypeScript, React components) and Flutter (the Dart language, its own widget toolkit). Kotlin Multiplatform is a newer option that shares business logic in Kotlin while each platform keeps its own UI.
- Web-based: a mobile website or a Progressive Web App (PWA), sometimes wrapped in a thin native shell. Cheapest to build, but with the most limited access to device features and store distribution.
How React Native works
This course uses React Native because you already know React. In React Native you still write components, props, state and hooks, but instead of rendering HTML elements you render native views. A <View> becomes a real UIView on iOS and an android.view.View on Android; a <Text> becomes a native text view. Your JavaScript runs in a JavaScript engine (Hermes by default) inside the app, and React Native's renderer turns your component tree into the platform's own UI widgets.
That is the key difference from a web view: the buttons, scrolling and text input are the platform's real controls, so they behave the way users expect. Since React Native 0.76 the "New Architecture" is the default: JavaScript talks to native code through JSI (a direct C++ interface) instead of the old asynchronous "bridge", which makes calls into native code faster.
Flutter takes a different route. It does not use the platform's widgets at all; it draws every pixel itself with its own rendering engine. That gives very consistent visuals across platforms, at the cost of re-implementing platform look and feel.
Comparing the options
| Concern | Native (Swift / Kotlin) | React Native | Flutter |
|---|---|---|---|
| Codebases | Two | One (plus small native parts) | One |
| Language | Swift, Kotlin | JavaScript / TypeScript | Dart |
| UI controls | Platform's own | Platform's own, via React | Drawn by Flutter |
| New OS features | Available on day one | Usually needs a library update | Usually needs a plugin update |
| Team fit | Separate iOS and Android skills | Web and React developers | Teams willing to learn Dart |
A worked example makes this concrete. Imagine a small team building a booking app for a gym: class lists, sign-in, push reminders and payments. They have two web developers who know React. A cross-platform framework lets them ship to both stores with one codebase, and React Native lets them reuse their React knowledge, so React Native is a sensible choice.
Now imagine a different team building a professional photo editor that uses the newest camera APIs, custom GPU filters and Apple Pencil pressure on iPad. Here the app lives on platform-specific features and heavy graphics, and the team would likely go native, at least for the editing screens.
Most real decisions are not all-or-nothing. Many React Native apps contain some native modules written in Swift or Kotlin, and many native apps embed a few web views for help pages. You will meet "when to go native" again in Mobile App Production.
Common mistakes
- "Cross-platform means write once, run everywhere with no extra work." You still test on both platforms, handle platform differences (back button on Android, gestures on iOS, permission dialogs) and sometimes write platform-specific code with
Platform.OS. - "Cross-platform apps are always slow." For typical business apps (lists, forms, navigation) a well-built React Native or Flutter app feels native. Performance problems usually come from how the app is written, such as rendering huge lists badly, not from the framework itself.
- Choosing a stack by hype. Choose by the team's skills, the features the app needs and how long it must be maintained.
- Forgetting the web. If users only need to read content once in a while, a responsive website may be enough and skips store review entirely.
Quick recap
- Native means one app per platform in Swift or Kotlin: the most direct access to the platform, at the cost of two codebases.
- React Native renders real native views from React components written in JavaScript; Flutter draws its own UI with Dart.
- Pick based on team skills, required device features, performance needs and long-term maintenance.
- Real apps often mix approaches: cross-platform for most screens, native modules where needed.
Try it
Open the Do tab and take the quiz to check that you can explain the trade-offs to a teammate.