In short
- Native means one app per platform, written in Swift and Kotlin with each platform's own tools.
- Cross-platform frameworks like React Native and Flutter share most of the code between iOS and Android.
- A progressive web app skips the stores, at the cost of some device features.
- Cross-platform suits most product apps well. Native pays off when the app depends on platform features or demanding performance.
Also called: Native app development, Cross-platform app development, React Native vs native, Flutter vs native.
The three main options
Native. An iOS app is written in Swift, today usually with SwiftUI for the interface, in Apple's Xcode. An Android app is written in Kotlin, usually with Jetpack Compose, in Android Studio. That makes two codebases, each using its platform's components and APIs directly.
Cross-platform. React Native, from Meta, lets you write apps in JavaScript or TypeScript with React and renders the platform's own interface components. Flutter, from Google, uses the Dart language and draws its own interface, so the app looks the same on both platforms unless you style it per platform. Both produce real apps that install from the stores.
Progressive web app (PWA). A website that can be installed to the home screen and keep working offline. It ships without the stores and updates like any website. On iPhone, web push notifications work only after the user adds it to the home screen, and access to device features is narrower than in a store app.
There are middle paths too. Kotlin Multiplatform, for example, shares business logic across iOS and Android while each platform can keep its own native interface. Wrapping a website in an app shell is another shortcut, and it usually feels like one. Choie builds real iOS and Android apps rather than wrappers.
Native and cross-platform side by side
How the two approaches differ
Native
- One codebase per platform
- New OS features available first
- Platform look and feel by default
- Two sets of specialist skills
Cross-platform
- One shared codebase for most code
- New OS features may need native code
- One team can ship both apps
- Some native code still needed
| Factor | Native | Cross-platform | Progressive web app |
|---|---|---|---|
| Languages | Swift (iOS), Kotlin (Android) | JavaScript or TypeScript (React Native), Dart (Flutter) | HTML, CSS, JavaScript |
| Codebases | One per platform | One shared, plus some native code | One, shared with the website |
| Device features | Everything the OS offers | Most, through plugins or native modules | A narrower set that varies by browser |
| New OS features | Usable as soon as the OS ships them | Often need a plugin update or native code first | Arrive when browsers add them |
| Distribution | App Store and Google Play | App Store and Google Play | From the browser, no store needed |
| Updates | Through store review | Through store review | Live as soon as you deploy |
When native is worth it
- The app lives on platform features. Widgets, watch apps, advanced camera or audio work, augmented reality, or deep health data. Some of these, such as iOS home screen widgets, have to be written in Swift anyway.
- Performance is the product. Both frameworks perform well for typical apps. The gap shows in heavy graphics, real-time audio or video, and complex gestures on older phones.
- You only need one platform. If your users are almost all on iPhone, a native iOS app avoids an extra layer for little added cost.
- Your team is native. People build best in the tools they know, and so do the people who will maintain the app later.
When cross-platform or a PWA is the better call
For most product apps (accounts, forms, lists, feeds, payments, maps), a cross-platform framework covers what you need with one team and one codebase. React Native suits teams that already work in React on the web. Flutter suits teams that want one custom look drawn the same way on both platforms. Expect some native work regardless, since permissions, push setup, and payments touch each platform's own configuration.
If the job needs neither the stores nor deep device features, a PWA or a responsive web app may be the cheapest first release. Many teams start there and add store apps once the product is proven. When Choie scopes a build, the number of platforms is one of the main things that moves the price, so it is decided in writing before work starts. A custom mobile app covers which phone features make an app worth building, and an MVP keeps the first version small whichever route you take.
Common mistakes
- Choosing on benchmarks. In typical apps users rarely notice the framework. They notice slow servers, heavy images, and confusing flows.
- Assuming zero native code. Cross-platform apps still need platform work for permissions, notifications, payments, and store builds.
- Ignoring who maintains it. A stack nobody on the team knows well turns into technical debt quickly.
- Building both platforms before learning anything. One platform or a web app can show you what to build next.
Choie designs and builds web, iOS, and Android apps from $19,000 in four to six weeks, with a written scope and a fixed total before work starts. See pricing, or get in touch to talk through which approach fits your product.
Common questions
Is React Native or Flutter better?
Neither is better across the board. React Native fits teams that know React and want the platform's own interface components, while Flutter fits teams that want one custom look drawn the same on both platforms. Both are mature and run large production apps.
Do cross-platform apps feel native?
For typical apps, usually yes. Users rarely notice the framework when the design follows each platform's conventions and the app is well built. Gaps tend to show in heavy animation, complex gestures, and brand-new OS features.
Can I switch from cross-platform to native later?
Yes, though it means rewriting the app's screens and logic. The back end, the designs, and what you learned about your users all carry over. On a Choie project, the designs and source code are the client's once each deliverable is paid for, so a later rewrite can start from them.
Is a progressive web app enough instead of a store app?
It can be, if your users do not expect to find you in an app store and the job needs no deep device features. On iPhone, web push requires adding the app to the home screen first, so fewer people will get your notifications.