Native or cross-platform: how to choose for your first app

For most first apps, cross-platform is the right starting point, and sometimes a good web app is enough. Native earns its extra cost when the product depends on something the phone does that a shared codebase handles badly. The hard part is being honest about which of those describes your app.

This is how we work through the decision with founders.

The three options, in plain terms

Native: separate apps for iOS (Swift) and Android (Kotlin). Each gets full access to its platform, and you maintain two codebases.
Cross-platform: one codebase, usually React Native or Flutter, that ships to both app stores. Most of the code is shared, with some platform-specific work at the edges.
Web app: runs in the browser on any device and can be saved to the home screen. No store listing, no review queue, and updates go live the moment you deploy.

People usually frame this as native versus cross-platform. The web app belongs in that conversation too, especially for a first release.

Start with what version one has to prove

A first app is an experiment with a budget. Before anyone talks about frameworks, write down the two or three things the first version must prove. "Homeowners will check progress in the app instead of phoning the site manager." "Drivers will log deliveries without being chased." Things you could actually observe within a few weeks of launch.

Then list what the app needs to do to prove them. Most first versions are forms, lists, dashboards, chat, payments and notifications. All three options handle those well. If that's your app, the decision comes down to cost, speed and who maintains it, and nobody's favorite technology should win the argument.

When native is worth it

We recommend native when the app leans hard on the device itself:

Continuous background work, like tracking location along a delivery route or recording a workout.
Bluetooth hardware, wearables or accessories you need to talk to reliably.
Heavy camera, audio or AR processing where lag is visible to the user.
Platform features such as widgets, watch apps or system integrations that you need on day one.
Graphics-heavy interfaces where smooth animation is part of the product.

Cross-platform frameworks reach most device features through plugins or small native modules. But if the core of your product lives in that layer, you'll spend a lot of your time there anyway, and a native build removes a layer of translation. You also get new OS features as soon as Apple and Google release them, without waiting for a framework or plugin to catch up.

The cost is real, though. Two codebases mean two sets of bugs, two release schedules and usually two skill sets on the team. For a founder watching runway, that's the main reason to hesitate.

When cross-platform is the sensible default

For a typical product app, cross-platform gives you one codebase, one team and one roadmap across both stores. Fix a bug and it's fixed on both platforms. Ship a feature and you ship it once. It also costs less to maintain, which matters more in year two than it does on launch day.

React Native suits teams that already work in JavaScript or TypeScript, because the website and the app can share people and some logic. Flutter draws its own interface, so screens look the same across devices. Both are sound choices. We pick based on the team that will own the app after launch, since that decides more about the next two years than any benchmark.

Two caveats. "One codebase" doesn't mean zero platform work: you still test on both systems, handle their different permission prompts and design conventions, and now and then write a bit of native code. And you're taking on a dependency on the framework's release cycle. Both are manageable if you plan for them.

When a web app is enough

A web app is the quickest way to put something real in front of users, and it's often overlooked. You skip store review, you can ship fixes several times a day, and anyone with a link can try it. If your users mostly open the product on a laptop, or only a few times a week, a web app may be all version one needs.

The trade-offs: there's no store listing to be found through, some device features are limited in the browser (more so on iPhone), and notifications and background tasks are less dependable than in an installed app. If the product has to keep working while the phone is in someone's pocket, a web app usually won't do.

A real example: HomeSutra Living

HomeSutra Living, based in Indore, helps families build a home from design to move-in with one accountable partner. We designed and built their digital product end to end, and its shape is a good illustration of combining options instead of picking just one.

There's an Android app, plus a web app that covers iOS and desktop. In both, homeowners track construction milestones live, see photo updates from the site, chat with their project manager and verify payments. Around that sit an AI design lab that turns a short description and a chosen style into home design concepts, a cost calculator with package comparisons, and a landing page with WhatsApp and consultation booking.

In practical terms, that structure puts the core features on every device without a separate native iPhone app to build and maintain. Tracking milestones, viewing photos, chatting and checking payments are the kind of features that work well in a browser, so the web app is a reasonable home for them on iPhone and desktop. The landing page sits on the open web, where search and ads can reach it. You can read more in the HomeSutra case study.

The wider lesson: your "app" might really be two or three surfaces with different jobs. Decide surface by surface.

Questions to settle before you choose

Bring answers to these to your first planning call:

Which phones do your users actually carry? If you sell into a specific market, find out rather than guess.
Does the core experience need the phone to do something special, or is it screens, data and messages?
How often will you ship changes in the first three months? If the honest answer is "constantly", a web app or a single cross-platform codebase will feel much lighter.
Who maintains this after launch, and what do they already know?
What would make you rebuild it in a year? If you can name it, design for it now.

What we usually recommend

For a founder with a first product and a fixed budget, our default is a cross-platform app, or a web app if the product doesn't need a place on the home screen yet. We move to native when one of the device-heavy needs above sits at the center of the product, and we say so early, because it changes both the budget and the timeline.

Whatever you choose, a few things matter more than the framework: a tight scope for version one, analytics in place before launch so you can see what people actually do, and a release process that makes the second version easy to ship. Those decide whether the app keeps improving or stalls after launch.

If you're weighing this up for your own product, our iOS & Android apps team is happy to talk it through.