The short version: build a web app when your product is reached through a link; build a native app when your product lives on someone's home screen. Most products are the first kind — but the ones that are genuinely the second kind waste years pretending otherwise. Here's how to tell which one you're building.
The one question that decides most cases
How does a user arrive at your product on a normal day? If the honest answer is "they search, click an ad, or follow a link — maybe a few times a month", the browser is your platform: zero install friction, one codebase, instant updates, and every marketing channel lands directly on the product. If the honest answer is "they open it on purpose, repeatedly, as a habit", you're building for the home screen — and the native platform starts paying rent.
When native earns its keep
- Habit-frequency use. Daily or near-daily sessions justify the install; occasional use rarely does.
- Offline as a feature, not a fallback. Timetables on the MTR, flashcards on a flight — if the product must work with no signal, native storage and native behavior win.
- The device itself is the product. Precise location, camera pipelines, widgets, Live Activities, HealthKit, background processing — capabilities a browser can't reach or can't reach reliably.
- Push that people accept. Notification permission converts far better inside a purposeful native app than from a website prompt.
- The App Store as a channel. Store search and featuring are distribution; being installable is trust. For some categories, "is there an app?" is the credibility question itself.
- Interface feel that sells the product. Games and interaction-heavy tools live or die on latency and polish; native buys headroom no runtime can match.
When a web app is the smarter build
- Acquisition-led products. If growth comes from search, ads or content, the click must land on the product — not on a store listing asking for a 100MB commitment first.
- Occasional-use tools. Booking, quoting, dashboards, portals: nobody wants an app they open six times a year.
- Fast-moving products. One deploy updates every user instantly — no review queue, no version fragmentation.
- Tight budgets that must cover every platform. One responsive codebase reaches iPhone, Android and desktop on day one.
- Anything that must be linkable. If sharing a URL is core to the product, the web is not just the channel — it's the product's grammar.
The middle paths — and their honest trade-offs
Progressive Web Apps close part of the gap (installable, offline-capable, push on most platforms) and cross-platform frameworks share code while shipping real store apps. Both are legitimate — we build with them where they fit. The honest trade-off: a PWA never quite feels installed on iOS, and a cross-platform app is still two store presences to maintain. The middle paths reduce cost, not responsibility.
The decision in five questions
- Does a normal user arrive by link, or by habit?
- Must it work offline — as a feature, not an apology?
- Does it need hardware or OS surfaces a browser can't reach (widgets, sensors, background work)?
- Is the App Store a real acquisition or credibility channel in your category?
- Can the budget honestly sustain two platforms' worth of releases — forever?
Score it plainly: mostly link-shaped answers → web first, wrap it native later if habit emerges. Mostly habit-shaped answers → native first, with a marketing site that converts. Genuinely split → web product plus a native companion for the habitual core, which is how a lot of the best products are actually structured.
What this looks like in practice
We build both sides for a living — marketing sites and web apps engineered for Core Web Vitals and conversion, and native iOS & Android apps in Swift and Kotlin, including our own shipped apps — so we have no framework religion to sell you. Builds are fixed-scope with the price quoted upfront: web development · app development.