Why We Build Most Apps Cross-Platform, and When We Say Native
We build most client apps cross-platform, from a single codebase that ships to both the App Store and Google Play. We go native when the app leans hard on device hardware, when it renders its own graphics, when a platform-only surface like a watch app is the point of the product, or when you already employ iOS and Android engineers. That is the whole decision rule, and this post is about how we arrived at it and where it breaks.
It matters to you because it is the largest single lever on your budget after scope. The same feature list built twice in native code costs close to twice as much as building it once, and that difference is usually the difference between shipping this quarter and shipping next year.
What cross-platform actually means now
Two frameworks dominate: React Native and Flutter. Both compile to real native app binaries. Neither wraps a website in an app shell, which is what people usually picture when they hear "cross-platform" and why the phrase still carries a reputation it stopped deserving several years ago.
Both are also past the rough patch that gave them that reputation. React Native's rewritten internals, the New Architecture, have been the default since version 0.76, which removed the old asynchronous bridge between JavaScript and native code that caused most of the jank people remember. Flutter ships on a steady quarterly cadence, with 3.47 as the current stable release as of September 2026.
We use React Native for most builds. That is a hiring decision more than a technical one: the JavaScript talent pool is far deeper than the Dart pool, so if you ever take the code in-house or hand it to another shop, you have more people to hand it to. Flutter is the better choice when an app is heavy on custom drawn interfaces and identical branding across platforms. Both are legitimate. Anyone who tells you one is simply better is selling their own bench.
Why one codebase is the default
The cost argument is the obvious one. Adding the second platform to a cross-platform build typically adds about a fifth to a third of the original price, not another full build, because the screens, the business logic, and the API layer are already written. You can see how that plays out against feature scope in our breakdown of what an app actually costs, or run your own numbers through the free app cost calculator.
The argument that matters more over time is maintenance. A bug reported on Android is one fix, one review, one release. With two native codebases it is two fixes written by two people who will interpret the ticket slightly differently, and eventually the apps drift apart in small ways nobody planned. Two years after launch, that drift is what makes the app expensive.
The third reason is simpler. Most business apps are lists, forms, detail screens, a camera, push notifications, and a login. That is exactly the workload these frameworks handle without complaint. Reaching for native to build a booking app is like buying a truck to carry groceries.
The four cases where we say go native
Sustained, real-time hardware access. Occasional camera or GPS use is fine cross-platform. Continuous work is not: a Bluetooth Low Energy connection held open to a medical or industrial device, background audio processing, live location tracking that must survive the app being backgrounded for hours. These paths live in platform-specific code with platform-specific failure modes, and wrapping them in a bridge means you debug both the bridge and the hardware.
Rendering your own graphics. Games, 3D product configurators, real-time video effects, augmented reality. If the app draws every pixel itself rather than arranging standard interface components, use the platform's own graphics stack, or a game engine built for it.
A platform-only surface is the product. Apple Watch apps, complications, widgets, CarPlay, Android Auto, share extensions, keyboard extensions. You write these in Swift or Kotlin regardless of what the main app uses. When they are a small companion piece, we build them natively alongside a cross-platform main app and that works well. When they are the reason the product exists, the cross-platform layer is only overhead.
You already have native engineers. If you employ two iOS developers, the cheapest app you will ever own is the one they can maintain without retraining. Technical fit follows team fit more often than people admit.
Reasons we do not accept
"Native feels faster" is not one, by itself. For a list of records fetched from an API, users cannot tell, and we would rather spend that budget on the parts of the app they can tell — fewer taps to complete a task, offline behaviour that does not lose their work, a launch screen that does not stall.
"Investors expect native" is not one either. Nobody in a due diligence process has asked us what the app was built in. They ask who owns the code and the store accounts, which is a fair question and one we answer plainly in our post on account ownership.
What cross-platform actually costs you
Three real costs, so you can weigh them rather than discover them.
- The upgrade tax. Frameworks release often and dependencies fall behind. Budget a maintenance window once or twice a year to move to a current version. Skipping it for two years turns a routine upgrade into a rewrite.
- Native modules. Anything the framework does not cover needs a small piece of platform code written and maintained. Most projects need one or two. It is normal, not a failure, but it is work.
- Harder debugging at the seams. When something breaks between JavaScript and the platform, you need someone who understands both sides. That person is rarer and costs more than a general mobile developer.
None of these outweigh the savings for a typical business app. All of them outweigh the savings for the four cases above.
Where we are the wrong choice
If you are building a game, hire a studio that ships games. If your app's core value is a novel camera or sensor pipeline, hire native specialists for that piece even if we build everything around it. If you already have a mobile team and you are looking for extra hands rather than a delivery partner, a staffing firm will serve you better than we will, because our process assumes we own the outcome.
We would rather tell you that on the first call than three months into a build.
How we decide on a specific project
We ask four questions before quoting. What hardware does the app touch, and for how long at a stretch? Does anything need to run while the app is closed? Is there a watch, widget, or in-car surface in the first year? Who maintains this in two years, us or your team?
Two of those answers pointing native is enough for us to recommend native, even though it is the more expensive quote and the slower schedule. Recommending the cheaper build for an app that needs the expensive one is how projects end up rebuilt.
If you want us to run those questions against your idea, describe it in the app brief and we will tell you which way it points, along with what each route would cost.
Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.
Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.
