Web App or Native App: How to Choose

Few product decisions are as expensive to reverse as the choice of platform. Whether you build a browser-based web application, a native app for iOS and Android, or a progressive web app that sits somewhere in between shapes your budget, the features you can offer, how people find and install your product, and how fast you can ship a fix on a bad Friday afternoon. The debate over web apps versus native apps is usually framed as a technical question, but for the person commissioning the work it is a commercial one: which option delivers the capabilities your users need at a build and maintenance cost you can sustain for years, not months.

This handbook is written for business owners, product leads, marketers and in-house teams who are about to brief an agency or a development partner. It explains what you are really choosing between, which requirements should drive the decision, what makes each route cost more or less, how to compare supplier proposals on equal terms, the warning signs in a pitch, and how to judge the result once it is live. Practitioners will find the detail they need to sanity-check a recommendation; buyers will find the questions that expose a weak one.

One principle runs through everything that follows: decide on the platform after you have listed what the product must do, not before. Suppliers often arrive with a preferred stack, and a preferred stack is not a strategy.

Web apps versus native apps: what you are actually choosing between

There are three realistic options on the table, plus a family of hybrids that blur the edges. Understanding each in plain terms prevents you from comparing proposals that are quietly describing different products.

Web applications

A web app runs in the browser. Users reach it through a URL, a search result, an email link or a bookmark. There is no store listing and no install step. One codebase, built with HTML, CSS and JavaScript (usually with a framework such as React, Vue, Svelte or Angular), serves desktop and mobile alike, adapting its layout responsively. When you deploy a change, every user gets it on their next page load. The trade-off is that the browser mediates access to the device, so some hardware and operating-system features are limited or unavailable, and the experience depends on the browser the user happens to have.

Native apps

A native app is built for a specific operating system using that platform's own languages and toolkits: Swift and SwiftUI or UIKit for iOS, Kotlin and Jetpack Compose for Android. It is distributed through the Apple App Store and Google Play, installed on the device, and has the deepest access to hardware, background processing, system integrations and platform UI conventions. The cost is that each platform usually means a separate codebase, and every release passes through store review before users can download it.

Progressive web apps

A progressive web app (PWA) is a web app that adds a web app manifest, a service worker and HTTPS so that it can be installed to the home screen, launch in its own window, cache content for offline use and, on supporting platforms, receive push notifications. Google's web.dev guidance on progressive web apps covers the building blocks in depth. A PWA keeps the web's single codebase and instant updates while closing part of the gap with native, which is why it deserves serious consideration whenever reach matters.

Cross-platform and hybrid frameworks

Frameworks such as React Native, Flutter, .NET MAUI and Kotlin Multiplatform let one team share much of the code between iOS and Android while still shipping store-distributed apps with substantial native access. Wrapper approaches such as Capacitor package a web app inside a native shell. These are legitimate options, but they are still native apps from a distribution point of view: they go through store review, they need platform-specific work for some features, and they carry their own upgrade cycles. Treat them as a way to reduce the cost of the native route, not as a way to avoid its obligations.

Start with a capability inventory, not a platform preference

The single most useful document you can produce before talking to suppliers is a capability inventory: a list of every device feature, integration and behavior the product needs, each marked as essential at launch, needed within a year, or nice to have. It comes first for a reason. Most platform arguments dissolve once the list exists, because either a hard requirement forces native or nothing on the list does.

Features that usually push toward native

• Sustained background work. Continuous location tracking while the app is closed, background audio with rich lock-screen controls, or long-running uploads that must survive the app being swiped away.
• Deep hardware integration. Bluetooth Low Energy peripherals on iOS, NFC beyond basic tag reading, advanced camera controls such as manual exposure or depth data, and health or fitness sensor frameworks.
• System integrations. Home-screen widgets, watch apps, car integrations, share extensions, Siri or Assistant shortcuts, and wallet passes that update in place.
• Heavy real-time graphics. Games, augmented reality and media editing where frame timing and GPU access matter.
• Store-driven discovery or purchasing. If your acquisition plan depends on app store search, featuring or in-app purchase flows, you need a store presence.

Features the web handles well

• Content, catalogs, account dashboards, booking and ordering flows, forms and checkout.
• Camera capture for photos and document upload, geolocation while the page is open, and file handling.
• Offline reading and queued submissions through service workers and client-side storage.
• Web push notifications, including on iOS for web apps added to the home screen on recent versions, with caveats about the install step that users must complete first.
• Payments through standard checkout flows and browser payment request support.
• Passkeys and password-manager autofill, provided the forms are built properly, a subject covered in our guide to designing for password managers.

Browser support changes with every release, so do not rely on a list like this one, including ours, for a final answer. Ask your supplier to verify each essential item against current browser and operating-system versions and to show you a working proof, which leads to the next practice: prototype critical features before committing. A two-to-five-day spike that proves a Bluetooth pairing or an offline sync on real devices is cheap insurance against a multi-month build on the wrong foundation.

Write the inventory in user terms

Phrase each capability as a user outcome with a test, not as a technology. "Drivers can record delivery proof with a photo while they have no signal, and it uploads when they reconnect" is testable and platform-neutral. "Needs native camera" is a conclusion disguised as a requirement. Written this way, the inventory becomes the acceptance criteria you will later use to judge the result.

What drives the cost of each route

Suppliers price platform work very differently, and published price figures vary so widely that we will not quote any. What we can do is name the drivers, so that you can see why two quotes differ and whether the difference is justified.

Number of codebases and teams

The largest structural driver is how many clients you are building. A responsive web app or PWA is one client. Fully native on iOS and Android is two clients, usually with two specialist skill sets, plus the web if you also need a desktop or marketing presence. Cross-platform frameworks share much of the code, but not all of it; platform-specific modules, testing on both operating systems and store submissions remain separate tasks. Duplicating teams without need is a common mistake, and it is often where budgets quietly double.

Design effort per platform

Native apps are expected to respect platform conventions: navigation patterns, system typography, back behavior, sheet and dialog styles, and permission prompts differ between iOS and Android. A good design team adapts a shared design system to each platform rather than forcing one layout onto both. Web apps need their own responsive breakpoints and must work with mouse, touch and keyboard. Interaction details still matter everywhere; decisions such as when to use buttons versus links or how large to make tap targets, grounded in Fitts's law and target size, apply to every route and should be priced into design regardless of platform.

Backend and integrations

The server side, APIs, authentication, payments and third-party integrations cost roughly the same whichever client you choose, and they are frequently the larger share of the work. A proposal that shows a dramatic saving from choosing web over native, while the backend estimate is unchanged, is usually right; one that shows a saving on the backend because of a client choice deserves questioning.

Testing matrix

Each platform multiplies the devices, operating-system versions and browsers you must test. Native apps need testing across screen sizes and supported OS versions on both platforms; web apps need testing across browser engines, including Safari on iOS, where all iOS browsers have historically used Apple's WebKit engine. Ask how the supplier defines the supported matrix, because it drives both build and maintenance effort.

Ongoing maintenance

Plan for the cost of maintaining each platform. Native apps need updates when Apple and Google release new OS versions, raise their minimum SDK targets or change store policies, even if you add no features. Web apps need dependency updates and browser-compatibility fixes. Developer program memberships, certificates, crash reporting, analytics and CI build minutes are recurring line items. A reasonable planning assumption is that maintenance is a continuous annual cost rather than an occasional one; ask each supplier to state their own estimate and what it includes.

Distribution, app store review and update speed

How your product reaches users, and how quickly you can change it, is the second axis of the decision and the one most often underestimated by first-time buyers.

Store distribution: benefits and obligations

App stores give you a trusted install path, a listing that can be found through store search, ratings, and built-in payment rails. In exchange, every build is reviewed against the platform's rules. Apple's developer documentation, including the App Store Review Guidelines, sets out requirements on privacy disclosures, account deletion, in-app purchase for digital goods, login options, minimum functionality and more. Google Play has its own policies and target-SDK deadlines. None of this is onerous if you plan for it; all of it is painful if you discover it at submission, which is one of the most common and avoidable mistakes in native projects.

Review cycles versus update needs

Weigh app store review cycles against how often you need to ship. Review times vary and are usually quick for routine updates, but a rejection can add days, and even after approval users must install the update. Some will run an old version for months, which means your backend must support several client versions at once and you need a forced-upgrade mechanism for breaking changes. A web app, by contrast, updates for everyone on the next load. If your product changes weekly in response to pricing, regulation or campaigns, that difference matters. If it changes quarterly, it matters less.

Discovery and acquisition

Ask where your users will come from. If most arrive through search engines, email, social posts or QR codes, a web app catches them at the moment of intent with no install step between the link and the task. Every extra step loses some people, and "download our app" is a large step for a one-off task. If users come from app store browsing, or the product is a daily habit that benefits from a home-screen icon and notifications, the store is worth its friction. Many businesses end up with both: a web experience for acquisition and occasional use, and a native app for their most engaged customers.

Compliance and consent

Both routes carry privacy obligations. Native apps must complete store privacy labels and, on iOS, request permission before tracking across apps. Web apps must handle cookie consent in the jurisdictions where it applies; our piece on cookie banner design covers the choices that affect both compliance and conversion. Budget design and legal review time for whichever set applies.

Offline use, performance and the myths that distort the decision

Several beliefs about the web are out of date and push buyers toward native builds they do not need. Two stand out: building native apps for content that is fine on the web, and assuming the web cannot handle offline use.

A common belief is that a web app stops working the moment the connection drops, so anything used in the field has to be native. In reality, with a service worker and client-side storage, a web app can load its shell offline, show cached data, and queue user actions to sync when the connection returns. What varies is how much storage the browser grants and how reliably background sync runs on each platform, so offline-heavy products should be prototyped on the actual devices users carry.

What offline support really involves

Offline capability is a design problem before it is a platform problem, on any route. You need to decide which data is cached, how long it stays fresh, what the user sees when they are offline, how conflicts are resolved when two edits collide, and how the interface signals that an action is pending rather than complete. Long forms are a common case; our guide to saving progress in long forms covers autosave and draft recovery patterns that apply whether the form lives in a browser or a native app. A native build does not answer these questions for you; it just gives you different storage and background APIs to implement the answers with.

Performance

Native apps have an edge in startup time for heavy apps, animation smoothness under load and access to the GPU. For content, forms and dashboards, a well-built web app is fast enough that users cannot tell the difference, and a badly built native app can be slower than a good website. The drivers of perceived speed on the web are well documented: bundle size, image weight, server response time and layout stability. Ask suppliers which performance budgets they will commit to and how they will measure them, rather than accepting "native is faster" or "web is fast enough" as a slogan.

Security and trust

Regulated sectors sometimes assume native is inherently more secure. Both can be built securely or insecurely. Native apps offer hardware-backed key storage and biometric APIs; the web offers passkeys, strict transport security and content security policies. The practical difference is often about perceived trust and platform features such as biometric login, which is why banking products commonly offer both a web and a native client. Our practical guide to banking app UX explores how those expectations shape the experience.

Questions to ask a supplier before you sign

The quality of a platform recommendation shows in how the supplier arrived at it. Use the questions below in your first meeting and ask for written answers in the proposal. A strong partner will welcome them; a weak one will answer with generalities. If you have not commissioned an outside team before, our guide on working with external design teams covers briefing and governance in more depth.

Pay particular attention to the last three questions. Ownership of signing keys and store accounts is easy to overlook and hard to recover if a relationship ends badly; the accounts should be registered to your organization from day one, with the supplier added as a team member. The migration question tests whether the supplier has thought about the product's future or only about the current contract.

Comparing quotes side by side

Proposals for platform work are notoriously hard to compare, because suppliers structure them differently and may be quoting different products under the same name. Normalize them before you look at totals. Ask every supplier to price against the same capability inventory and the same supported matrix, then score each proposal on the criteria below. Weight the criteria to your situation; a product with heavy device requirements should weight capability fit higher, and a campaign-driven product should weight update speed and reach.

Score each proposal from 1 to 5 on every row, multiply by weight, and only then compare prices. It is common for the cheapest quote to score poorly on the rows that drive long-term cost, which is where the real price of a platform decision sits.

A worked example: an illustrative appointment-booking product

The following example is illustrative, not a client project. It shows how the capability inventory and cost drivers lead to a decision, using effort in person-weeks rather than prices, because rates vary widely by region and supplier.

A regional chain of physiotherapy clinics wants customers to book, reschedule and pay for appointments, complete intake forms, receive reminders, and view exercise videos between sessions. Most bookings come from search and from links in reminder emails. Staff want a tablet view of the day's schedule that keeps working when the clinic Wi-Fi is unreliable.

The inventory

• Booking, rescheduling and payment: essential at launch, fully supported on the web.
• Intake forms of 20 to 40 questions: essential, a web strength, benefiting from autosave and a multi-step structure.
• Appointment reminders: essential; email and SMS cover all users, with push notifications as an enhancement.
• Exercise videos: essential, streamed video works well in the browser.
• Staff schedule offline: essential, achievable with a service worker caching the day's data.
• Wearable integration for exercise tracking: nice to have in year two, the only item that would push toward native.

The options, with illustrative effort

Note that the backend effort does not change between options; only the client work does. The PWA covers every essential item, catches customers arriving from search and email without an install step, and lets the clinic update prices and opening hours instantly. The one native-leaning item is optional and a year away. The sensible recommendation is a PWA now, with the API designed so that a native client could be added later if wearable integration proves valuable. Designing the intake flow well matters more to this client than the platform; our guide to multi-step forms is directly relevant.

Change one input and the answer changes. If the clinics' main product were a daily home-exercise program with motion tracking through wearables, the essential list would contain native-only capabilities, and the cross-platform option would become the better value despite its higher effort.

Red flags in platform proposals and pitches

Most poor platform decisions are visible in the proposal if you know where to look. Beyond the cost warning above, watch for the following patterns.

None of these alone proves a proposal is bad, but each should prompt a direct question. A supplier who can explain why they recommend what they recommend, in terms of your inventory and your users, is showing you how they will make the hundreds of smaller decisions to come.

Scope that hides platform differences

Another subtle flag is a design scope that shows one set of screens for all platforms. Platform conventions for controls such as toggle switches, navigation, dialogs and date pickers differ, and a proposal that ignores them tends to produce an app that feels slightly foreign on every device. Ask to see how the design system adapts per platform, and how the web version handles keyboard and screen-reader users.

How to judge the result once it ships

Acceptance should test the promises that justified the platform choice, not just whether the screens match the designs.

Behavioral data after launch is also the right basis for revisiting the decision. If a large share of your most engaged users repeatedly return through the browser and ask for notifications or a home-screen icon, that is evidence for either a PWA install prompt or a native app. If an app's install base stays small while web traffic grows, the app may be costing more than it earns.

Making the call and when to bring in help

For most businesses, the decision comes down to a short set of rules. Build for the web, ideally as a PWA, when your product is content, commerce, forms, bookings or dashboards, when users arrive from links and search, and when you need to change things quickly. Build native, or cross-platform native, when an essential capability depends on it, when the product is a daily habit that earns a place on the home screen, or when store distribution is part of your acquisition plan. Build both when your audience splits into occasional visitors and highly engaged regulars, and sequence them so the shared backend is designed once.

Bring in help when you are choosing a platform strategy, before any build is contracted. An independent review of the inventory, a short prototype of the riskiest feature and a comparison of options costs a small fraction of a rebuild. Our UI and UX design service covers platform strategy, prototyping and the design systems that let one product feel right across web, iOS and Android, and you can find more practical guides in our UI and UX design articles.

Where this comes from

• web.dev — Progressive Web Apps
• Apple Developer — App Store Review Guidelines

The figures and practices above come from the sources listed.

Working on something like this?

We take on UI & UX Design work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• A Practical Guide to Name and Address Fields for Global Users
• How to Get Inclusive Form Fields Right