TL;DR: For most business apps, cross-platform is now the correct default and native is the deliberate exception you buy for a named reason. That reason is almost never "it feels faster." It is usually one of four things: the app has to keep working with the screen off, it sits close to the hardware, the interface itself is the product, or you already employ native teams. The choice is also rarely all or nothing, because the shape that wins most often is one shared codebase with native modules for the hard ten percent. Here is how to decide, and what to ask a vendor before you commit to a stack you will live inside for years.
"Should we build native or cross-platform?" is usually asked as a technology question and answered as one, which is why so many teams end up with a stack that fights them in year two. The useful version is not which framework is better. It is which parts of your product genuinely need the operating system's full cooperation, and who is going to maintain the thing after launch. Answer those two honestly and the stack mostly picks itself. After shipping mobile products, cross-platform SDKs and game clients across four continents, here is the decision model we use before anyone writes a line of code.
The four things people mean by "the stack"
Fully native means Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android. Two codebases, two build pipelines, two sets of platform knowledge, and complete access to everything each OS can do the day it ships.
A cross-platform framework means React Native, Flutter or Kotlin Multiplatform. One codebase covering most of the product, with a documented escape hatch down to native code when you need it. The frameworks differ in how they draw the interface, which matters more than most buyers expect and we will come back to it.
A wrapped web app means your web product in a native shell, via Capacitor or a progressive web app. It is genuinely the cheapest path onto a phone and genuinely the most limited. For an internal tool or a companion view of something that already lives on the web, it can be exactly right. For a consumer product competing on feel, it usually is not.
A game engine means Unity, and it is a separate category rather than a fourth option. If your product is real-time 3D, it is an engine decision, and the mobile games we have shipped, Color Sort 3D, Lumber Doge and Snatch A Hat, do not belong in the framework conversation at all.
Five questions that actually decide it
1. What does the app have to do when nobody is looking at it?
This is the single most predictive question and almost nobody asks it in the first meeting. Foreground work is well covered by every option. Background execution is where cross-platform gets thin, because iOS and Android disagree about it profoundly, each guards battery in its own way, and frameworks abstract the comfortable eighty percent while the awkward twenty percent is exactly what your product may depend on.
Long audio recording is the clean example. LectureNotes AI, our note-taking app, exists to record a lecture and turn it into a clean outline, which means the recording has to survive the screen locking, an incoming call, a low-memory moment and an hour of elapsed time. That is a background-execution problem before it is an AI problem. Continuous location, persistent network connections and sync that happens while the user is elsewhere land in the same category. Geonode's Repocket SDKs, which let users earn by sharing unused bandwidth, do real networking on the device in the background, which is precisely why capability like that is packaged as native modules under a cross-platform surface rather than written once in framework code and hoped for.
Ask what your app does with the screen off. You will learn more about the right stack than any feature list will tell you.
2. How close to the hardware do you sit?
Draw a line between hardware access that is well trodden and hardware access that is a research project. Reading a QR code is well trodden. Covoisino, a ride-sharing app for hitchhikers we built, uses QR verification to keep rides safe, and that kind of camera use is supported cleanly on every option here. Processing every camera frame in real time is a different animal, and so are low-energy Bluetooth to a device you also make, secure enclave and biometric work, NFC, and anything reading raw sensor streams at high frequency.
The honest third answer is that sometimes the work does not belong in a phone app at all. Raqts, the responsive racquet-sport wall we handle software for, is computer vision plus IoT, and the vision runs where the cameras and the hardware are rather than inside a mobile client. If your hard problem looks like that, read how we scope computer vision products before choosing a mobile framework at all.
3. Is the interface the product, or the path to it?
Two different requirements hide inside "it has to look good," and they push toward different frameworks. One is that the app should feel like it belongs on the device, matching the platform's own controls, gestures, scrolling physics and accessibility behavior, including the ones the OS changes next year. The other is that it should look identical to your brand on every device, which is a different goal and sometimes the opposite one.
Frameworks that render platform components inherit the first for free and fight for the second. Frameworks that draw their own interface get the second by design and chase the first every time an OS ships a redesign. Neither is better in the abstract, and a consumer product competing on feel and an internal tool used by trained staff have genuinely different answers. A vendor who does not ask which one you are should worry you.
4. Which platform actually has to exist on day one?
The second platform is never free, even with one shared codebase. It brings its own store review, its own device matrix, its own crash reports and its own support load. Teams routinely pick cross-platform to launch on both stores at once, then discover they doubled the surface they have to keep stable while still learning whether the product works. For a first version the discipline is the same one that keeps MVP budgets under control: pick the one surface where the product has to live, prove the loop, and let the second platform be earned. A cross-platform stack is a good way to keep that door open cheaply. It is not a reason to walk through it immediately.
5. Who maintains this in year two?
Every stack choice is also a hiring decision, and this is the part buyers underweight most. Two native codebases means two skill sets on the payroll or on retainer forever, and a permanent synchronization tax where every feature is specified once and built twice, and the two builds drift in small ways that turn into support tickets. One shared codebase with occasional native modules means one team, plus a specialist when you reach the hard ten percent.
Pick the stack your future team can actually staff and afford, not the one that looks best in an architecture diagram. The trade-offs are the same ones we lay out for talent augmentation: a narrow, well-defined surface fits a small team, and every extra platform widens it permanently.
Where cross-platform genuinely stops being the right answer
Being honest about the exceptions is what makes the default trustworthy. Cross-platform is the wrong call when:
- Your product is real-time 3D or a game. That is an engine build with its own economics, covered in what game development costs.
- Your product runs on a headset. XR is not a mobile framework question at all. Headsets are their own target with their own tooling, as our work on ARCortex's ERIS XR and Nystag's VR eye-tracking diagnostics shows, and the scoping model differs enough that we wrote what an XR app costs separately.
- The product lives in the OS surface, not in the app. Home screen widgets, watch apps, live activities, share extensions, CarPlay and Android Auto are built natively regardless of what your main app is written in. If those are the product rather than a garnish, plan for native.
- You already have two strong native teams. The best stack is often the one your people are excellent at, and rewriting a healthy native app to consolidate codebases has to justify itself against every feature you are not shipping while you do it.
It is almost never all or nothing
The shape that wins most often in practice is a shared codebase carrying the great majority of the product, with native modules written for the specific places that need them. The background audio path, the Bluetooth stack, the frame-processing pipeline, the platform-specific permission dance: each becomes a small, well-bounded piece of native code with a clean interface, and the rest of the app calls it without caring. That is the same discipline as building an SDK, a small stable surface over a complicated machine underneath.
The practical version for you as a buyer is one question to any vendor recommending cross-platform. What is your escape hatch to native, and when did you last use it? A team that has written native modules will answer immediately and tell you what they had to drop down for. A team that has never needed to has probably never shipped an app that pushed on the boundary. Insist that boundary gets drawn during scoping, with the expected native pieces named on paper, so nobody discovers them halfway through the build.
What the choice actually costs
Two native codebases is not double the price, because the parts that dominate a real budget are shared: product thinking, design, backend, integrations and testing strategy. What it adds is a tax that never ends. Every feature is specified once and implemented twice, every bug is potentially two bugs, and every OS release is two upgrade paths. Cross-platform inverts that trade: a smaller ongoing tax, in exchange for an occasional sharp cost when you hit something the framework does not cover and have to drop to native, plus a dependency on the framework's own release cadence. Neither is free. The mistake is comparing only the first invoice.
How AI changes the math
The mechanical share of platform work, the per-platform boilerplate, the glue, the tests and the second implementation of a screen you already designed, is exactly what AI coding agents now handle well under senior review. We wrote up how in our ship-in-days playbook. The practical effect is that maintaining two native codebases is less punishing than it was a few years ago, which slightly weakens the strongest historical argument for cross-platform.
What has not moved is the judgment. Deciding which ten percent needs native, designing the boundary between shared and platform-specific code, and knowing which OS behavior will bite you next release is taste built from having been bitten. Ask any vendor how AI factors into their platform strategy and expect a specific answer about where it helps and where it does not.
Questions to ask before you commit
- What does this app do when the screen is off, and how does your recommended stack handle it?
- Which parts do you expect to write as native modules, and why those?
- Is the interface meant to feel like the platform or like our brand, and which does your recommendation optimize for?
- What happens when the next major iOS or Android version ships, and who is responsible for that upgrade?
- Which of your recent apps used this stack, and where did it push back on you?
- If we launch on one platform first, how much of the work carries to the second?
- Do we own the source and the build configuration, or only the app in the store?
That last one matters more than it sounds. The stack you pick is what every future decision inherits, so owning the code and being able to hand it to another team is the real insurance policy. It is the same clause we recommend for anyone launching a software product.
Where we fit
We build across both worlds, from mobile apps like LectureNotes AI, Lifemaxxing AI and Covoisino to cross-platform SDKs for Geonode and engine builds for game clients. That range is why we can recommend a stack without a house preference to defend, and why we will tell you when the honest answer is that your hard problem is not a mobile framework problem at all.
Trying to decide between native and cross-platform for a real product? Book a demo and we will walk through the background, hardware and team questions with you, including telling you if a simpler build gets you there. See our work: LectureNotes AI, Covoisino, Geonode's Repocket SDKs and more, shipped in days, not months.