Native vs cross-platform: which app should you build?

For the large majority of business apps in 2026, cross-platform is the right default. React Native and Flutter have both been in serious production use for close to a decade now, they ship apps that ordinary users cannot distinguish from native, and they cost meaningfully less to build and much less to maintain than two separate native codebases.

Native is still the correct answer for a specific and fairly narrow set of apps: games and graphics engines, real-time camera or augmented reality work, heavy background processing, and anything that has to use a brand-new iOS or Android capability the week it launches. If your app is a booking tool, a client portal, a scheduling app for field staff, a member app, or a store, that list does not describe you.

I have been building software from one office in Edina for 14 years, and the pattern I see with Twin Cities clients is consistent. The framework decision almost never determines whether the app succeeds. Scope discipline does.

What is the difference between native, cross-platform, and web-based apps?

There are three families, and it helps to be precise about what each one actually is.

Native means writing the app twice, in each platform’s own language and tools. iOS in Swift with SwiftUI, built in Xcode. Android in Kotlin with Jetpack Compose, built in Android Studio. Two codebases, usually two developers or two teams, one product.

Cross-platform means one codebase that compiles or runs on both platforms. React Native uses JavaScript or TypeScript and renders real native iOS and Android interface components, which is why a React Native button is an actual platform button. Flutter uses Dart and draws every pixel itself with its own rendering engine, which is why a Flutter app looks identical on both platforms whether or not you want it to. Kotlin Multiplatform is a third option that shares business logic while leaving the interface native on each side, and it has matured a lot for teams that already write Kotlin.

Web-based means the app is a website inside a native shell. Capacitor is the current standard here; it takes a web app, wraps it in a real app that installs from the store, and gives it plugin access to the camera, GPS, and push notifications. A progressive web app, or PWA, skips the shell and the store completely: it is a website the user installs to their home screen.

If any of those terms are new, the glossary has plain-language definitions for most of them.

How do the three approaches compare?

	Native (Swift + Kotlin)	Cross-platform (React Native, Flutter)	Web-based (Capacitor, PWA)
Typical build cost, both platforms	$35,000-$120,000+	$20,000-$75,000	$8,000-$30,000
Timeline to a first real release	5-9 months	3-6 months	6-14 weeks
Performance	Ceiling is highest. Matters for games, 3D, video processing	Very good. Indistinguishable for lists, forms, maps, media playback	Adequate for content and forms. Noticeable on heavy animation
Device features	Everything, on day one	Nearly everything through plugins. Unusual hardware may need native code	Common features only. iOS restricts background work
Look and feel	Perfectly platform-correct	React Native uses real platform controls. Flutter draws its own, consistent everywhere	Feels like a website unless carefully designed
Team you need	An iOS developer and an Android developer	One mobile team. Web developers transfer to React Native easily	Your existing web developers
Yearly maintenance	Roughly double. Two OS upgrades to absorb each fall	One upgrade cycle, one dependency tree	Lowest. Mostly the same work as your website
Update speed	Store review for every change	Store review, but JavaScript-layer fixes can ship over the air	Instant for web content. Store review only for shell changes
App store	Fully accepted	Fully accepted, including by very large apps	Capacitor accepted if it does real app things. PWA needs no store

Two notes on that table. First, over-the-air updates are a genuine operational advantage of React Native and Capacitor: a copy fix or a small bug fix in the JavaScript layer can reach users the same day without waiting for review. Apple permits this within limits, and the limit is roughly that you cannot change what the app fundamentally is between reviews. Do not build a business plan around dodging review.

Second, app review itself is faster than its reputation. Most submissions come back within a day or two. The delays that hurt projects come from rejections over privacy disclosures, account deletion requirements, and payment rules, not from queue time.

What does the second codebase actually cost?

This is the number people get wrong in both directions. Two native codebases do not cost twice as much, because design, backend and API work, content, testing plans, and project management are shared regardless of approach. But the client-side engineering genuinely doubles, and that is often half the project.

In practice, the second native platform adds roughly 60 to 80 percent of the first platform’s engineering cost. Across a whole project, choosing one codebase over two typically saves 30 to 40 percent, not 50.

Project	One shared codebase	Two native codebases
Simple app, roughly 8-12 screens	$20,000-$32,000	$32,000-$55,000
Standard business app with accounts, payments, notifications	$35,000-$60,000	$55,000-$100,000
Complex app with offline sync and integrations	$60,000-$75,000+	$100,000-$160,000+
Year two maintenance and OS updates	$5,000-$18,000/yr	$10,000-$32,000/yr

Our published range for a mobile app covering iOS and Android is $20,000 to $75,000, and that assumes a shared codebase. See the full pricing page for how that sits against web and web-app work, and the detailed cost breakdown for apps for what moves a project from one end of the range to the other.

The maintenance line is the one that quietly decides this. Apple and Google both ship a major OS release every fall, and both periodically require new submissions to be built against a recent SDK. With one codebase that is one round of testing and fixing a year. With two it is two, forever.

When is cross-platform the right default?

When the app’s job is moving structured information between people. That covers most of what businesses, clinics, schools, and nonprofits actually need:

• Client or member portals, appointment booking, and intake
• Scheduling, timesheets, and visit verification for field staff
• Content and media apps, event apps, donation apps
• Ordering and store apps
• Internal tools that need to work in a truck, a school hallway, or a client’s home

For all of these, the bottleneck is your API and your data model, not the rendering engine. Both React Native and Flutter handle lists, forms, maps, camera capture, push notifications, biometrics, offline storage, and payments through mature, well-maintained plugins. Several of the largest consumer apps in the world run on React Native, and several very large financial apps run on Flutter, which is the practical answer to “will it scale.”

The one honest caveat: cross-platform is one codebase, not zero platform knowledge. You still need someone who understands App Store review, provisioning profiles, Play Console releases, and how push notifications differ on each side. A team that has only ever built websites will lose weeks learning that.

When should you build native instead?

Five cases, and they are real:

1. Games and heavy graphics. If you are rendering a 3D scene or running a physics loop, use a game engine or go native. Do not use a business app framework for this.
2. Intensive camera, video, or AR. Real-time filters, on-device computer vision, document scanning with custom processing, ARKit or ARCore experiences. Taking a photo is easy anywhere; processing 60 frames a second is not.
3. Serious background processing. Continuous location tracking, background audio pipelines, large sync jobs that must run while the app is closed. Both platforms restrict this heavily, and the escape hatches are native.
4. Deep platform integration. Home screen widgets, watch apps, Siri or Assistant integration, CarPlay, complex share extensions. Some of this is possible with a native module bolted onto a shared codebase, but if there are five such features, the shared codebase stops paying for itself.
5. Day-one adoption of new OS features. If your product has to demo the newest iOS capability during the same keynote week, native is the only route.

Notice what is not on that list: “we want it to feel premium.” Feel is a design and performance-tuning outcome. A well-built React Native app beats a badly built native one every single time.

Which should you build for your type of app?

App type	Recommended	Why
Client portal or member app	Cross-platform	Forms, lists, and auth. Nothing here needs native
Home care or field staff scheduling	Cross-platform	Offline data and GPS check-in are solved problems
Clinic or therapy practice app	Cross-platform	Intake and messaging. Spend the budget on security instead
School or district app	Cross-platform, or none	Often a mobile-friendly website plus push does the job
Nonprofit donor or volunteer app	Usually none	A good website converts better. See the section below
Online store companion app	Cross-platform, or your platform’s own app	Shopify and similar already offer one
Booking and payments for a service business	Cross-platform	Stripe and the store payment rules matter more than framework
Photo, video, or scanning product	Native, or hybrid with native modules	Real-time processing is the whole product
Game or 3D experience	Game engine or native	Wrong tool otherwise
Delivery or dispatch with constant tracking	Native, or cross-platform with a native location module	Background location is the hard part
Internal tool used on company devices	Web app or Capacitor	No store, no review, cheapest path

Should you build a web app or a PWA instead?

Often, yes, and this is the option most people skip past too quickly.

If your users are on a computer as much as a phone, or if you need people to reach the tool from a link without installing anything, a web application is cheaper to build, cheaper to run, and updates instantly. Our web app range is $12,000 to $60,000, and a lot of what people describe as an app idea is really a portal. The difference between a web app, a website, and a mobile app is worth ten minutes before you commit budget.

Progressive web apps deserve a fair hearing too. On Android a PWA installs to the home screen, works offline, and sends push notifications. On iOS the story is weaker: home screen web apps do support push, but background processing, hardware access, and integration are limited, and you get no App Store listing. If discovery through the App Store is part of your plan, a PWA is not enough. If your users are staff or existing clients, it may be plenty.

Do you actually need an app at all?

Here is the part that costs us money to say: most of the organizations who contact us about a mobile app should not build one.

An app has to be found in a store, downloaded, kept on a phone, and opened again. That is four barriers a website does not have. If the app’s job is to show information, take a form, accept a donation, or let someone request a callback, a fast mobile website does all of it for $3,500 to $9,000 instead of $20,000 or more, and it shows up in Google search where people are already looking. A nonprofit weighing a $30,000 app against a $6,000 site and $24,000 of program spending is not really facing a technology decision.

The test I use: an app is justified when people will open it more than once a week, or when it needs to work with no signal, or when it is the product you sell. Otherwise, build the site. Website or app walks through that decision in more detail, and how to build an app without wasting $50,000 covers scoping if you decide to proceed.

One more thing against our own interest: if what you need is a game, an AR product, or a real-time video pipeline, we are not your studio. Find a team that builds that specific thing every day. We will say so on the first call rather than take the project and learn on your budget.

What does TayoPro build, and why?

We build cross-platform apps for iOS and Android from a single codebase, and we add native modules where a specific feature requires them. That is a deliberate choice for the clients we serve: Twin Cities clinics, home care and disability service providers, schools, nonprofits, and small businesses. They need reliable software for years on a fixed budget, not the last five percent of frame-rate performance.

We also spend a lot of the first conversation trying to reduce scope. Most apps that fail do so because version one carried nine features instead of three, launched late, and ran out of money before anyone used it. A shared codebase helps with that, but only if the scope is honest.

Most of our work is on the web side, which you can see across our portfolio and our mobile app development service page. We serve clients across the Twin Cities and greater Minnesota from our Edina office.

If you have an app idea and want a straight answer about whether it should be an app, a web app, or a better website, get in touch. No charge for the conversation, and I will tell you if the cheaper option is the right one.