One codebase, two platforms, and the trade-offs stated plainly

What a shared codebase actually buys you

The case for cross-platform app development is usually made as a saving, and the saving is real — but it is smaller and differently shaped than the pitch implies.

What you genuinely share is everything that has nothing to do with the operating system: data models, business rules, validation, networking, caching, state management, most screen layouts, analytics instrumentation and the majority of the tests. On a typical product that is most of the code, and an even larger share of the code that changes after launch.

What you do not share is everything at the edges. Push notification configuration, background execution, permission flows, deep links, biometric authentication, in-app purchase, home-screen widgets, share sheets and the camera stack all still have to be built, configured and debugged twice, because they belong to two different operating systems that happen to be reachable from one language.

So the honest version of the benefit is not “half the cost”. It is: one team rather than two, one backlog rather than two, one release plan, and features that arrive on both platforms in the same week instead of three months apart. For most companies that second list is worth more than the first, because an Android app that is permanently a release behind is a product problem long before it is a budget one.

Choosing between Flutter and React Native

We do not have a house framework. The choice turns on your team and your interface, and a firm that answers before asking about either is telling you about itself rather than about your project.

Flutter draws its own widgets rather than using the platform’s. Rendering goes through Impeller, which precompiles its shaders at engine build time — the fix for the shader-compilation stutter that gave earlier Flutter releases their reputation for first-run jank. Impeller is now the only renderer on iOS and the default on modern Android. Drawing everything yourself buys precise control and identical output across platforms, which suits design-led products and heavy custom animation. It costs you Dart as a language you must hire for, and it means platform-standard controls are reimplementations rather than the real thing.

React Native renders actual native views. Its New Architecture — Fabric for rendering, TurboModules for native access, and the JavaScript Interface replacing the old serialised bridge — has been the default since version 0.76, and Hermes is the default engine, compiling JavaScript to bytecode ahead of time so startup does not pay a parse cost. If you already employ React engineers, or you have a web product whose types and business logic could be shared, that adjacency is worth more than any benchmark.

In practice the decision comes down to four questions. Who can you hire where you are? How much of your interface is custom rather than standard platform components? Do you share code or types with a web application? And do maintained bindings already exist for the specific SDKs you must integrate — the payment provider, the mapping vendor, the hardware you talk to over Bluetooth? That last question has settled more framework decisions than any performance argument.

The third option nobody mentions

If your product’s differentiator is that it feels exactly right on each platform, but you would still rather not write your business logic twice, Kotlin Multiplatform shares the logic and leaves each interface fully native. It is more work than a single codebase and considerably less than two complete apps. It is the right answer more often than its market share suggests.

Where cross-platform is the wrong answer

It is easier to trust a recommendation if you know what it is not.

Cross-platform is a poor fit when the core of the product sits at the edge of what the operating system allows. Real-time camera processing and augmented reality, low-latency audio, sustained background location, deep health and fitness integration, and products with a wide surface of platform extensions — widgets, watch apps, CarPlay, Android Auto — all have the same shape of problem: the shared layer is doing very little for you while adding a bridge to maintain and debug. Games belong in a game engine, not in either framework.

It is also the wrong answer when your audience is overwhelmingly on one platform. If nine in ten of your users are on iOS, a second codebase is not the problem you have, and you are paying an abstraction tax for a platform you barely serve. Native iOS work or a dedicated Android build will be simpler and better.

And no framework rescues a thin product. Apple’s review guidelines are explicit that an app should offer more than a repackaged website, and section 4.2 is among the most commonly cited grounds for rejection. If the plan is essentially to wrap an existing site, changing the technology does not change the verdict.

Where the shared code stops: platform channels and native modules

Every cross-platform project has a seam, and the quality of the app is largely decided by how deliberately that seam is drawn.

Flutter crosses it with platform channels: asynchronous message passing between Dart and native code, with Pigeon available to generate type-safe bindings rather than hand-writing string-keyed method names. React Native crosses it with native modules built on the JavaScript Interface, which lets JavaScript hold direct references to native objects instead of serialising every call across a bridge.

The mechanics matter less than the discipline. We define the narrowest interface we can in shared code, implement it once in Swift and once in Kotlin, and document both. A wide, chatty bridge is where cross-platform apps go to become slow and unmaintainable; a narrow, typed one is barely visible in a profile.

The other discipline is dependency auditing. A shared codebase makes third-party packages tempting, and a package containing native code is a liability on someone else’s maintenance schedule. Before adopting one we look at when it last shipped, whether it supports current OS versions, what its licence permits, and whether we could realistically fork and maintain it if the author stopped. “There is a package for it” and “there is a maintained package for it” are different claims, and only one of them is a plan.

Making one app feel like two native apps

Users do not identify frameworks. They identify conventions, and they are unforgiving about them.

The back gesture is the obvious case: on Android it is a system-level expectation every screen must honour, and on iOS it is an edge swipe with its own animation and its own feel. Then there are date and time entry, the share sheet, scroll physics and overscroll behaviour, haptics, how a modal dismisses, where a primary action sits, how permission prompts are worded and when they are asked. Typography is a category of its own — Dynamic Type on iOS and the system font scale on Android both mean your layout has to survive text two sizes larger than the design assumed.

Our approach is one design system with a written list of deliberate exceptions, using Material Design 3 and the Apple Human Interface Guidelines as the two grammars. That exceptions list is the valuable artefact, because divergence that is decided is cheap and divergence that is discovered during App Review is not. Where the interaction design is a substantial part of the project we run it as product design work in its own right rather than as a styling pass over shared components.

Performance: the honest picture

Most business applications are not limited by their framework. They are limited by network calls, image sizes, over-fetching and doing work on the main thread — problems that are identical in a native app and get blamed on the framework anyway.

Where a shared codebase can genuinely lose ground is narrower than the internet suggests: cold start, because there is an engine or a JavaScript bundle to initialise before the first screen appears; long lists with complex cells, where the cost of reconciling a view hierarchy shows up; heavy image and video manipulation; and animation driven from application code on low-end Android hardware.

All four are measurable, so we measure them. Cold start time, frame timings during scroll and transitions, and memory use on a mid-range device three years old become budgets agreed at the start rather than opinions exchanged at the end. The device that matters here is not the one on the developer’s desk. An app tested only on a current flagship has not been tested.

Testing two platforms without doubling the work

The shared codebase pays a real dividend in testing, but only if the test strategy respects where sharing stops.

Unit tests over business logic, validation and state transitions run once and cover both apps — that is the dividend, and it is a large one. Widget or component tests over the interface layer also run once. End-to-end tests have to run per platform, on real devices, because that is precisely where the two apps differ.

Manual testing should then be aimed at the seams rather than spread evenly. The shared screens will behave the same on both platforms; that is the whole premise. What needs a human is the native module, the permission dialogue, the purchase flow, the push notification arriving while the app is backgrounded, and the deep link opened from a cold start. Effort spent re-checking identical shared screens twice is effort not spent where the risk actually lives.

Releasing without ceremony

Release automation is set up early, before there is anything urgent to ship. fastlane handles code signing, metadata, screenshots and upload to TestFlight and Google Play tracks; hosted runners from Codemagic or EAS Build remove the requirement that someone in the team owns a correctly configured Mac. Version bumping, changelog generation and staged rollout become part of the pipeline rather than a checklist somebody half-remembers.

The point is not elegance. It is that when a crash appears on a Friday afternoon, shipping the fix should be routine rather than an event that depends on one person being at their desk. Once the app is live, attention moves to the store listing itself, which is a discipline of its own — see app store optimisation for how ranking and conversion on the two stores are handled.

Migrating an existing native app

Both frameworks can be embedded inside an existing native app, which makes incremental migration possible, and incremental is nearly always right.

A big-bang rewrite quietly discards years of accumulated edge-case handling: the unusual subscription state, the customer who has been on the app since 2019, the manufacturer whose keyboard misbehaves, the retry logic somebody added after a bad week in production. None of it is documented, all of it was earned, and you rediscover it in the wild with real users attached.

So we start with a self-contained leaf screen — a settings page, a help section, something with few dependencies and a small blast radius — prove the integration, the build pipeline and the release process end to end, then move inward. It looks slower on a plan. It is faster in reality, and it can be stopped at any point without having already burned the existing app.

Living with a framework

Both frameworks move quickly, and neither supports old versions indefinitely. Deferred upgrades compound: skip enough of them and the eventual jump becomes a project rather than a task, which is how a cross-platform app turns into an unplanned native rewrite.

The mitigations are dull and effective. Keep the dependency count low. Prefer packages you could fork. Pin versions and upgrade on a stated cadence rather than in response to a deadline. And accept that some platform work arrives every year no matter what you built with, because Google Play enforces a rolling target API level requirement and Apple sets its own minimum SDK expectations for submissions. Budget for that as maintenance, not as a surprise.

If you want a view on whether a shared codebase suits what you are building — including the possibility that it does not — tell us what the app has to do and we will give you the reasoning rather than the recommendation.