"Which technology should we use?" is usually the second question in a brief, right after "how long will it take?". It matters, but less than people expect, and the right answer depends far more on the product than on which framework is fashionable this year.
Here are the three real options, explained without jargon, followed by the questions we use to choose between them.
Native: one app per platform
A native app is written in each platform's own language and tools: Swift and SwiftUI for iPhone, Kotlin and Jetpack Compose for Android. You build two apps that share a design and a backend but not their code.
Strengths
- The best possible performance and the most "at home" feel on each platform.
- Day-one access to new OS features: widgets, Live Activities, Apple Watch, new camera and health APIs.
- Fewer layers between your code and the device, which helps with demanding work like audio, video, AR or heavy graphics.
Costs
Two codebases mean more work to build and more work to maintain. Every feature is written twice, tested twice and can drift apart. For most first versions that doubling is hard to justify, unless the product lives on a platform-specific capability.
Cross-platform: one codebase, two store apps
Frameworks like React Native and Flutter let one codebase produce real iOS and Android apps that are installed from the stores. Done well, users cannot tell the difference from a native app.
Strengths
- Most of the code is written once, so iOS and Android stay in step and the budget goes further.
- Native modules are still available where they matter, so you are rarely boxed in.
- With React Native, parts of the code can be shared with a web version, and small fixes can often be shipped as over-the-air updates without waiting for a new store build, within the limits the store rules allow.
Costs
You are adding a framework between you and the platform. That is usually invisible, but new OS features can arrive a little later, and very demanding apps can hit limits. Doing cross-platform well also requires people who understand the native side; the "write once" promise covers most of an app, not all of it.
Web: an app that runs in the browser
A web app (sometimes a progressive web app, or PWA, that can be added to the home screen) runs in the browser on any device. No store, no install, one link.
Strengths
- The fastest way to reach people: anyone with a link can use it immediately.
- Search engines can find it, which an app inside a store cannot offer in the same way.
- Updates go live the moment you deploy. No review queue.
- Perfect for validating an idea before investing in store apps.
Costs
The browser still cannot do everything an installed app can. Notifications on iPhone only work for web apps added to the home screen, background tasks are limited, and some device features are missing or behave differently. Users also simply expect to find serious products in the App Store and Google Play.
The questions that actually decide it
- Which features are non-negotiable? If the core of the product is Apple Watch, deep camera work, AR or health data, lean native. If it is accounts, content, payments, chat and notifications, cross-platform handles it comfortably.
- Where are your users? In some markets Android dominates, in others iPhone does. If you need both from day one, a shared codebase saves a lot.
- How sure are you of the idea? Unproven ideas deserve the cheapest honest test, often a web app or a single cross-platform version.
- Who maintains it after launch? If you will hire a team later, choose a mainstream stack that is easy to hire for. Exotic choices age badly.
- What is the budget for year two? Two native apps cost roughly twice as much to keep current. That is fine if it is planned.
What we usually recommend
| Your situation | A sensible starting point |
|---|---|
| Testing an idea with real users, quickly | A mobile-first web app |
| A first store app on iOS and Android | Cross-platform (React Native), with native modules where needed |
| A product built around one platform's capabilities | Native for that platform first |
| An existing app that needs a watch, widget or extension | Native for that piece, alongside the main app |
That mix is how we work on our own products too. We ship our apps with over-the-air updates, and our Apple Watch work is written natively in SwiftUI, because a watch is exactly the kind of place where native pays off.
The most important thing is that the decision is made deliberately, during scoping, by the people who will build it, and written into the scope with the reasons. A technology choice you understand is far easier to live with than one you inherited.
Next step
If you are weighing these options for a real project, send us a short description of what the app must do and who it is for. We will recommend an approach in plain language and explain what it means for time and budget. And if you are still deciding whether you need an app at all, start with our honest test.