Mobile development
One codebase, or one per platform
Two vendors have told you opposite things and both were partly right — the answer turns on a few specifics about your app, not on which technology is better.
Ask us which one fitsWhy this choice is so hard to get a straight answer on
Both vendors were describing real projects, just not yours. A native studio remembers the camera app where the plugin lagged three months behind an iOS release; a cross-platform shop remembers the field-service app that reached both stores with one small team. Neither story tells you which one you are.
One question settles it more often than any other. What share of your app is screens, forms and API calls, versus work only the device itself can do? If the honest answer is mostly screens, cross-platform will serve you well and the argument is over.
Where it bites
Where the two actually diverge
Most comparison tables argue about things that stopped mattering years ago. These are the places where the choice changes what you can ship, and when.
Day-one platform features
Apple ships a new API at WWDC and native code can call it that week. Cross-platform waits for a plugin, or you write the bridge yourself.
Heavy device work
Continuous camera processing, Bluetooth Low Energy, background location and audio sit closest to the OS. Bridges are where those crash reports come from.
Perceived speed
Scrolling a list of API results feels the same in Flutter as in SwiftUI. The gap shows up in continuous rendering, not on ordinary product screens.
Two design languages
Material and the Human Interface Guidelines disagree about tabs, back navigation and date pickers. A shared codebase makes one audience feel slightly wrong.
Download size and cold start
A Flutter or React Native binary ships its own runtime, so the download is larger and the first launch slower than a native equivalent.
OS upgrade season
Every September iOS ships a major version. Native code usually needs a recompile. Cross-platform needs its framework, then every plugin you depend on, to catch up.
Hiring and handover
Two native codebases need Swift and Kotlin people on the same roadmap. One TypeScript codebase can be maintained by the web team you already have.
In-app purchases
Both go through StoreKit and Play Billing either way. Wrapper libraries lag on subscription edge cases like grace periods and price changes, so budget review time.
Watches, widgets and extensions
Home-screen widgets, watchOS apps and share extensions are written natively regardless of stack. Cross-platform teams end up maintaining a small Swift module anyway.
The trade-offs
Four dimensions people actually feel later
The differences above are technical. These four are the ones you will notice a year after launch, when the launch itself is long forgotten.
- TIME TO LAUNCH
- Cross-platform, when both stores matter
- One codebase reaching both stores usually beats two teams building in parallel, mostly because there is one set of decisions to make. If you only need iOS first, that advantage disappears entirely.
- COST OF CHANGE
- Cheaper cross-platform, until it is not
- Changing a shared screen edits one file rather than two. The exception is any change that reaches into the OS, where you now pay for the bridge as well as for the feature itself.
- WHO MAINTAINS IT
- Usually the team you already have
- React Native is maintainable by a competent web team. Flutter needs Dart, quick to learn but new to most. Native means keeping Swift and Kotlin skills on staff permanently, not just through launch.
- WHAT BREAKS FIRST
- Plugins, not your own code
- The failure is rarely the framework. It is an unmaintained community plugin wrapping a payment SDK or a barcode scanner, abandoned two years ago, that now blocks the next OS upgrade.
So which one should you pick?
Cross-platform is the right default for most apps we are asked to build, and we will say so even when the native version would be the larger engagement. Zyfolks builds both, so the lists below are the honest exceptions rather than a pitch.
Choose native if…
- The camera, sensors or Bluetooth are the product, not a feature.
- You need new iOS or Android APIs the week they ship.
- The app must feel unmistakably native to a design-literate audience.
- You are shipping one platform only, with no plan for the second.
Choose cross-platform if…
- The app is mostly screens, forms, lists and API calls.
- Both stores need the same feature at roughly the same time.
- One small team, or your existing web team, will maintain it.
- You are validating an idea and expect the scope to change.
Frequently Asked
Questions
Common questions about picking a stack, switching later, and what each choice costs to maintain.
Cross-platform is usually cheaper to build and to keep running, because there is one codebase, one test pass and one release process instead of two. The saving is not half, though. Design, backend, payments, QA and store submission barely change, and a genuinely device-heavy feature can cost more cross-platform than native once you have written the bridge yourself. If budget is the deciding factor, the bigger lever is scope. Fewer screens in version one beats any stack choice you could make.
Yes, and it is a reasonable plan if you say it out loud at the start rather than discovering it in year two. The realistic path is one screen or one flow at a time, since both React Native and Flutter can host native views inside an existing app. What makes it painful is a backend shaped around the mobile client instead of a clean API. Keep business logic on the server and the move becomes a UI job, typically spread over a few months.
On an ordinary product app, most will not. What they do notice is jank in gestures, a slow first launch, and controls that behave unlike every other app on their phone — a date picker that scrolls the wrong way does more damage than any small difference in frame timing. Those are all fixable in cross-platform, but they take deliberate attention rather than defaults. In a game, a camera product, or anything rendering continuously, users notice on the first screen.
Flutter draws its own widgets, so the app looks the same on both platforms and behaves predictably. The cost is Dart, and a look that is yours rather than the platform's. React Native uses the real platform components and is maintainable by anyone who writes TypeScript, which usually settles it for teams with an existing web stack. Both are backed by large companies and both are safe choices in 2026. Pick on the team you have, not on benchmark posts.
Worth asking, because it is cheaper than either option here and occasionally enough. A wrapped web view is fine for content, catalogues and internal tools, where having a store listing matters more than the experience inside it. It falls over on push notifications, offline behaviour, and anything touching the camera or background work. Apple has also historically rejected apps that are only a website in a shell. If none of those limits apply to you, take the cheaper path.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.