Native apps vs Cross-platform apps

Native development uses the platform maker’s own stack. On iOS that is Swift, with SwiftUI as the modern interface framework and UIKit underneath and alongside it, built in Xcode. On Android it is Kotlin, with Jetpack Compose as the modern toolkit and the older View system still present in many codebases, built in Android Studio. Older apps carry Objective-C and Java, and both still compile, but new native work is written in Swift and Kotlin. Each app calls its operating system directly, with nobody else’s runtime in between.

Cross-platform frameworks fall into three families, and the family matters more than the brand. React Native runs your code in a JavaScript engine and turns your components into the platform’s own native views, so the operating system still draws the controls. Flutter compiles Dart to machine code and ships its own rendering engine, which paints every pixel of the interface itself. Kotlin Multiplatform takes a different line: it shares the non-visual code, such as networking, storage, sync and domain rules, as a Kotlin library that both apps call, and leaves the interface to SwiftUI and Compose, or shares that as well through Compose Multiplatform. .NET MAUI, the successor to Xamarin, is the option for teams invested in C#.

Hybrid apps are web apps in a native frame. The interface is HTML and CSS rendered in a WebView, the logic is JavaScript, and a plugin layer reaches device features. It was the first practical way to ship one codebase to both stores, and through Ionic and Capacitor it is still a reasonable choice for internal tools, content-led apps and teams whose skills are entirely web. Its limits are the web’s limits inside an app: scrolling, gestures, transitions and text input that feel slightly off unless a great deal of care goes in, and performance that falls away on interaction-heavy screens and cheaper phones.

Store review also treats the categories differently at the margin. Apple’s guidelines reject apps that are little more than a repackaged website, so a thin hybrid shell around an existing site is at risk in review in a way that a genuine app built any other way is not. If what you have in mind is your website with an icon on the home screen, the progressive web app section further down is the more honest place to start.

Native is often described as costing twice as much, and that is wrong in both directions. Much of the work in a mobile product is shared whichever way you build it: product decisions, design, the backend and its API, the analytics plan, the store listings, signing and release, and a good deal of the test planning. What doubles is the client code and everything attached to it. Every screen built twice, every client-side bug investigated twice, every test suite written twice, every dependency upgraded twice, and every code review done by a different set of people.

The cost that arrives later is coordination. Two teams on two schedules drift. One platform finishes a feature first, the other is pulled onto an urgent bug, and within a few months the apps differ in ways nobody chose. Somebody has to own parity, reconcile two backlogs and decide whether a release waits for the slower platform. That role rarely appears in an estimate, and it is always needed.

Cross-platform has hidden costs of its own, and they should be stated plainly. You still need native skills, because some features will need a native module, and someone has to understand Xcode build settings, Gradle, provisioning profiles and the occasional crash that starts in native code. Debugging can cross three layers: your code, the framework and the platform. Framework upgrades are an extra recurring task, and a plugin you depend on can stop being maintained. None of this cancels the saving for a typical app, but a plan that assumes cross-platform means no native work at all is a plan that will slip.

A fair way to estimate is to list the features and mark each one as shared, shared with platform-specific edges, or native in either approach. A banking app with biometric sign-in, card provisioning to the phone’s wallet and a home screen widget has more entries in the last column than a booking app with accounts and payments. The size of that last column is what tells you whether a shared codebase is saving a great deal or very little.

Apple and Google each ship a major OS release every year, with developer betas available months before the public release. Native teams build against the beta SDK from the first week. If a new capability is central to your product, native is the only approach that guarantees it is available when the OS ships, because there is nothing between your code and the new API.

Cross-platform frameworks reach new APIs in one of three ways: the framework adds support, a plugin appears, or you write the bridge yourself as a small native module. For a non-visual API, such as a new permission flow or a new system service, the last route is usually a contained piece of work. For a new visual convention it is harder, especially for a framework that draws its own controls. When Apple redesigned its system look in 2025, apps built from standard native controls picked up much of the new appearance when rebuilt with the new SDK, while frameworks that render their own widgets had to reproduce it. React Native, because it renders native views, sits nearer the native end of that spectrum than Flutter does.

Then there is the part of a modern app that is not the app. Home screen widgets on iOS are built with WidgetKit and SwiftUI. Live Activities, watch apps, notification service extensions and share extensions are separate native targets, and Android’s home screen widgets, Wear OS apps and Android Auto integrations are native as well. A cross-platform app that needs them has native code living beside the shared code regardless. That is not a reason to abandon cross-platform, but it is a reason to count those features honestly before deciding.

The practical test is to write down the platform features on the next eighteen months of your roadmap and check, for each one, whether your intended framework supports it today, through what, and who maintains that code. If most of the list ends up native either way, the shared layer is covering less of the product than the decision assumed.

For a mainstream app, users cannot tell a well-built React Native or Flutter app from a native one, and most of the performance argument online concerns old framework versions or badly built apps. Native does set the ceiling, because it has the shortest path to the GPU, the threading model and memory, and because the vendors’ profiling tools are built around it. The useful question is whether your app ever comes near that ceiling.

Where the gap still shows is predictable. Cold start, because a framework runtime or engine has to start before the first screen appears. App size, because the framework ships inside the app. Sustained heavy rendering, such as long, complex, constantly updating lists or custom drawing. Real-time camera and media work, where frames cross from native code into the shared layer and back. And older, low-memory Android phones, where every layer of overhead is felt. If your users carry recent phones and your screens are forms and lists, none of these will matter. If many of them use entry-level Android devices, they matter a great deal, and you should profile a prototype on those devices before choosing.

Each approach also has its own way of going wrong. Native apps are not automatically fast: work on the main thread, oversized images and careless list implementations produce sluggish native apps every day. React Native slows down when the JavaScript thread is busy, when animations are not run natively, or when long lists are not virtualised. Flutter slows when too much of the widget tree rebuilds on each change. WebView hybrids struggle when a web interface tries to behave like a native one on an interaction-heavy screen, and that category is where the poor performance reputation of cross-platform development was largely earned.

Games are a separate decision. Anything with a game loop, physics or a 3D scene is usually built in a game engine, which is its own kind of cross-platform tool, and neither this comparison nor the app frameworks in it are the right frame for that work.

Users rarely know what an app is written in. They do notice when something behaves unlike every other app on their phone: a back gesture on Android that does the wrong thing, an edge swipe on iPhone that fails to go back, text selection handles that look foreign, a keyboard that covers the field being typed into, a date picker they have never seen, missing haptics, or an app that ignores their system font size. Native gets these details right without effort, because they come from the platform’s own components.

React Native inherits most of that behaviour because it renders native views, and that is its strongest argument on fidelity. Flutter reimplements it in its Material and Cupertino widget sets, closely enough that most users never notice, but the reimplementation has to be kept current as the platforms change. Kotlin Multiplatform with native interfaces gets the native result by definition. WebView hybrids have the furthest to go, because the browser’s defaults are the web’s rather than the platform’s.

There is a case where native fidelity is not what you want. If the product has a strong brand-led design system meant to look identical everywhere, platform conventions become something to override rather than inherit. Native then means building the same custom design system twice, once in SwiftUI and once in Compose, and keeping the two in step. That is the job Flutter was designed for, and for a design-led product it can produce a more consistent result than two native teams working to one specification.

Accessibility deserves its own mention, because it is often decided by accident. Native apps use VoiceOver, TalkBack and Dynamic Type through the platform’s own APIs. The mature cross-platform frameworks support all of them through their own layers, and the result can be excellent, but it has to be tested on both platforms with the assistive technology itself, never assumed. Where accessibility is a legal or contractual requirement, budget for that testing whichever approach you take.

Native implies two teams, or at least two people, with different languages, tools, libraries and review habits. That works well at a size where each platform has enough engineers to review each other’s work, cover holidays and share knowledge. It works badly with one iOS engineer and one Android engineer, because each platform then has a single point of failure and nobody is qualified to review the other’s code. If you cannot staff two platforms beyond that level, that alone is a strong argument for a single shared codebase.

A cross-platform team is one group working in one language on one backlog, which simplifies planning and makes parity the default. It still needs native depth somewhere. At least one engineer should be at home in Xcode and Android Studio, able to write a native module, read a native crash report, sort out signing and provisioning, and keep the build pipeline healthy through OS and toolchain updates. Teams without that person tend to find out at the worst possible moment, usually the week of a store deadline.

Kotlin Multiplatform suggests a third shape: a shared-logic group writing Kotlin, with iOS and Android engineers building native interfaces on top. It suits organisations with existing native teams who want to stop implementing the same rules twice without giving up native interfaces. It does ask iOS engineers to read, and sometimes write, Kotlin, which some welcome and some resist.

Whatever the shape, the backend, the API and the release process should belong to the same people, or to people who talk every day. Many mobile problems that look like client problems are really contract problems between the app and the server, and the structure of the team decides how quickly they are found. That holds for any form of mobile app development, and it gets less attention than the framework question while affecting the outcome more.

Mobile apps are never finished. Each platform ships a major OS release every year, deprecates APIs on its own schedule and raises the bar for store submission. Google Play requires apps to target a recent Android API level, and an app that falls too far behind stops being available to new users on newer Android versions. Apple periodically raises the minimum SDK and Xcode version it accepts for submissions. An app nobody maintains eventually cannot be updated in the stores at all, so budget for upkeep every year whichever way you build.

Native carries that load twice, in two codebases, with nothing in between. The advantage is that there is no third party to wait for: the vendor’s release notes describe what changed, and the fix is yours to make. Cross-platform carries it once, plus a layer: the framework’s own upgrades, which occasionally involve significant migrations, and the health of every plugin you depend on. A plugin abandoned by its maintainer becomes your code to maintain or replace, and a large app can depend on dozens of them.

WebView hybrids have aged worst on this measure. Many older Cordova apps are pinned to plugins nobody maintains, on build tooling that fights every new OS release, and end up rebuilt rather than upgraded. That history is a fair warning for every approach: the codebase that stays healthy is the one upgraded in small steps every few months, not the one left alone until a store deadline forces a large and risky jump.

Two habits reduce the cost of either approach. Keep dependencies few and deliberate, choosing first-party or well-maintained libraries over clever ones. And keep platform-specific code behind clean interfaces, so that an OS change or a framework change touches one place, not the whole app. The architecture that is easy to maintain looks the same in native and cross-platform work; only the number of places it has to be maintained differs.

Some products that arrive as a request for an app do not need one. A progressive web app is a website built to behave like an app: it can be added to the home screen, open full screen, work offline through a service worker, and send push notifications, including on iPhone for web apps added to the home screen. One codebase serves phones, tablets and desktops, updates reach every user at once, there is no store review, and purchases made through it are outside the stores’ commission.

It is the right answer more often than people expect: internal tools and field forms for staff, customer portals people visit occasionally, booking and ordering flows, dashboards, content and community products, and any first version whose main job is to prove that people want the thing. If most of your users would arrive from a link, a search result or an email rather than from a store, a PWA meets them where they already are, with no install standing in the way.

The limits are real, and mostly on iOS. Installation there is a manual step through the share menu rather than a prompt your site can trigger, so far fewer people install than on Android. Background processing is restricted, and device APIs that Chrome on Android exposes to the web, such as Bluetooth and NFC, are not available in Safari. There is no App Store listing, which matters if store discovery or the credibility of being in the store is part of the plan. On Android, a PWA can be listed on Google Play through a Trusted Web Activity, which gives you store presence without a separate codebase.

A sensible sequence for an uncertain product is to build the web app first, measure whether people come back to it, and build a store app when there is a concrete reason the web cannot meet, such as a device feature, notification reliability or the expectations of your market. If that reason never arrives, you have saved the cost of one or two mobile codebases, and their upkeep, for as long as the product exists.

Moving between these approaches is a rewrite of the client, and should be scoped as one. What survives is everything outside the app’s code: the backend and API, the designs, product decisions, analytics definitions, test scenarios, store listings and hard-won knowledge of where the edge cases are. What has to be rebuilt is the interface, navigation, state, client-side logic and every native integration.

Native to cross-platform can be done incrementally, which is almost always better than a big-bang rewrite. React Native can be embedded inside an existing native app, and Flutter supports the same through add-to-app, so new or rebuilt screens can move into the shared framework one at a time while the native shell keeps shipping. Kotlin Multiplatform is incremental by nature: you move one piece of logic at a time into a shared module and both apps start calling it, without touching the interface at all.

Cross-platform to native usually happens in part. The common pattern is that one demanding feature, a camera flow or a real-time view, moves to a native screen inside the cross-platform app while the rest stays shared. Provided the boundary is clean, that is a sound architecture. A full rewrite to native is justified when the product has moved decisively towards hardware, extensions or a single platform, and it should be argued as a business case with the same rigour as the original decision.

A common migration runs from an older Cordova or Ionic app that has become hard to upgrade or feels sluggish on newer phones. Web skills and much of the logic transfer readily to React Native, and moving from Cordova to Capacitor is a lighter step for teams staying with web technology. Before any of these, diagnose the actual complaint. Slowness often traces to one screen, an unvirtualised list or an oversized image, and a targeted fix costs a fraction of a rewrite.