Web App or Mobile App: Which Should You Build First?

Build a web app first when people use your product occasionally, at a desk, or find it through search. Build a mobile app first when they use it on the move several times a week, need push notifications to reach iPhone users without extra steps, or need device features and offline working that browsers on iPhone do not offer. Many products end up with both on one back end; the real decision is which one earns the first budget.

This guide is for founders and business owners in the UK, the US and Canada who are deciding where to spend the budget for a first digital product.

What are the options?

There are four main ways to deliver a product.

• Responsive web app. Runs in any modern browser on phone, tablet and desktop. There is one version to maintain, updates reach everyone the moment you release them, and there is no store review.
• Progressive web app (PWA). A web app with a manifest and a service worker, so people can add it to their home screen, open it full-screen, use parts of it offline and, with conditions, receive push notifications.
• Cross-platform app. One codebase that produces apps for both the App Store and Google Play. Flutter describes itself as a framework for "natively compiled, multi-platform applications from a single codebase" (Flutter, accessed Oct 2026). Which framework is right is decided per project, in the proposal.
• Native apps. Separate apps written in each platform's own language: Swift, which Apple describes as a language "for all Apple platforms" (Apple, accessed Oct 2026), and Kotlin, under Android's Kotlin-first approach (Android Developers, accessed Oct 2026).

No single approach is right for every product. We choose per project, to fit the scope and the proposal: for example, a cross-platform framework such as Flutter when one codebase should serve both stores, native Swift for a premium iOS-only app, or native Kotlin for an Android-first product.

What do your users actually need?

Start from how people will use the product. Five questions settle most cases.

How often will they use it?

A tool used a few times a year, such as booking an annual service, rarely earns a place on someone's home screen; people will follow a link instead. A tool used daily or weekly, such as logging hours or checking jobs, justifies an install, and the icon makes return visits easier.

Where will they use it?

People at a desk are well served by a web app on a large screen. Field workers, drivers and tradespeople need one-handed use on a phone, often with poor signal.

Which device features does it need?

Browsers handle more than many founders expect. Location is supported in every major browser (MDN, accessed Oct 2026), and web pages can use the camera with the user's permission (MDN, accessed Oct 2026). The gaps appear on iPhone and iPad:

• Bluetooth: Web Bluetooth is not supported in Safari (MDN, accessed Oct 2026).
• NFC: Web NFC works only in Chrome on Android (MDN, accessed Oct 2026).
• Background sync, which can finish an upload once the connection returns, even after the user has left the page, is not supported in Safari (MDN, accessed Oct 2026).

If your product reads sensors, scans tags or must send data while closed, plan for an app.

Does it need to work offline?

A PWA can cache screens and data for offline use, but browser storage is "best-effort" by default and can be cleared (see the iPhone section below). If losing an unsynced form would cost your users money, for example a site inspection in a basement, an app with proper on-device storage is the safer choice.

Do notifications drive the product?

If the product depends on reminders, alerts or new-job notifications reaching every user, check the iPhone rules below before you choose a PWA.

How will people find it: search or the app stores?

The two routes favour different products.

• Web. Pages can be indexed by search engines and shared as links in email, WhatsApp, ads and QR codes, and someone can go from a search result to using your product in one tap. That suits products people look for when they have a problem, such as "get a quote for a loft conversion".
• App stores. People search the stores by name or category, and an installed icon brings them back. But a new app competes with established ones, and the install is an extra step before first use. Stores work best when you can already send people there, through existing customers, a sales team or a website.
• Both on Android. A Trusted Web Activity opens your PWA from an Android app, with the link between the two verified through Digital Asset Links (Android Developers, accessed Oct 2026), so one web product can also have an Android app.

What do the app stores charge, and how does review work?

Both stores charge to publish, take a share of some payments and review what you submit.

Developer accounts. The Apple Developer Program is "99 USD per membership year", with prices shown in local currency during enrolment (Apple, accessed Oct 2026). Google Play charges "a US$25 one-time registration fee" (Play Console Help, accessed Oct 2026).

Commission on digital sales.

• Apple requires in-app purchase for digital features, subscriptions and premium content (guideline 3.1.1). Its Small Business Program offers a 15% commission to developers with up to US$1 million in proceeds in the prior calendar year and to developers new to the App Store (Apple, accessed Oct 2026).
• On the US storefront, Apple's guidelines allow buttons and links to other ways of paying (guideline 3.1.1(a)). Rules for other storefronts are stricter and vary by country.
• Google Play's fees depend on the market. In the UK, US and EEA, a new fee structure applied from 30 June 2026, with rates that vary by whether an install is new or existing and a separate billing fee (Play Console Help, accessed Oct 2026). Check the current table before you set prices.

Physical goods and services. If people pay for something used outside the app, such as a cleaner, a delivery or a site visit, Apple requires you to use other payment methods, "such as Apple Pay or traditional credit card entry" (guideline 3.1.3(e)). Store commission then does not apply, but your payment provider's fees do.

Review. Apple says App Review typically reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (Apple, accessed Oct 2026). Every update is reviewed, so a fix that goes live on the web in minutes waits, in an app, for approval and for users to update.

Privacy disclosures. Apple requires privacy details to submit new apps and updates, "including the practices of third-party partners whose code you integrate into your app" (Apple, accessed Oct 2026). Google Play requires a Data safety form for every app (Play Console Help, accessed Oct 2026).

What are the limits of a PWA on iPhone?

PWAs work on iPhone, but with conditions that affect products built around notifications and offline data.

• Push needs the Home Screen. Apple supports web push for "Home Screen web apps in iOS 16.4 or later" (Apple Developer Documentation, accessed Oct 2026). A user visiting your site in Safari cannot receive web push until they add it to their Home Screen.
• Permission must follow a tap. Apple's documentation says to let the user grant permission "with a gesture, such as clicking or tapping a button". You cannot ask on page load.
• Installation is manual. People add a site from the Share menu (WebKit, accessed Oct 2026), so your product has to explain how. Since iOS 26, every website added to the Home Screen opens as a web app by default, unless the user turns off "Open as Web App" (WebKit, accessed Oct 2026).
• Stored data can be evicted. WebKit stores web data on a best-effort basis by default. When space runs short, or after a period without user interaction, it deletes whole sites' data, least recently used first. A site can request persistent storage, which WebKit grants "based on heuristics like whether the website is opened as a Home Screen Web App" (WebKit, accessed Oct 2026).
• Some device features are missing, including Bluetooth, NFC and background sync, as listed above.

For many products these limits do not matter. For one that depends on alerts reaching every user, they decide the question.

What drives cost and maintenance?

Costs depend on scope, so treat the following as drivers to compare, not prices. For typical ranges, see our guide to website and app development costs in the UK, US and Canada.

• Number of codebases. A responsive web app is one codebase. Cross-platform apps add a second, for both stores. Native apps add one per platform, so each feature is built and tested more than once.
• The back end. Accounts, data, business rules, payments and notifications sit on a server whichever front end you choose. We build and host on AWS (Amazon Web Services), and one back end can serve a web app and mobile apps together, so adding a platform later does not mean rebuilding the core.
• Device features. Each native capability, such as background location or Bluetooth, adds work and testing on real devices.
• Store upkeep. The stores raise their technical minimums over time. For example, from 31 August 2026 new apps and updates on Google Play must target Android 16 (API level 36) (Android Developers, accessed Oct 2026). An app that falls behind has to be brought up to date before it can ship its next fix. Each release also needs store listings, privacy forms and a review cycle.
• Testing. Web apps are tested across browsers and screen sizes; apps also across OS versions and devices.

How does data protection change the decision?

The law follows the data, not the platform. A web app and a mobile app that collect the same personal data carry the same obligations: UK GDPR in the UK, PIPEDA for private-sector organisations in Canada, and state laws such as California's CCPA in the US. Under UK GDPR, the ICO requires data protection by design and by default, including limiting personal data "to what is necessary to achieve each specific purpose" (ICO, accessed Oct 2026).

Apps add three things to manage:

• Device permissions for location, camera and contacts, each requested in context, with a clear reason.
• Data stored on the phone, which belongs in the platform's secure storage (Keychain on iOS, Keystore on Android), not in plain files.
• Store disclosures that must match what the app and every third-party SDK in it actually collect. Each analytics or advertising SDK you add is something you must declare.

A web app has fewer of these moving parts.

This is general information, not legal advice. Confirm your obligations with a qualified adviser.

A decision framework: which should you build first?

Work through these questions in order and note each answer.

1. How often will a typical user open it? Monthly or less points to the web. Weekly or daily supports an app.
2. Where will they be? At a desk points to the web. On site or on the move points to an app or a PWA.
3. Which device features are essential? Location and camera work on the web. Bluetooth, NFC or work in the background point to an app.
4. Must it work without signal? Occasional offline viewing suits a PWA. Offline data entry that must not be lost points to an app.
5. Must notifications reach iPhone users without extra steps? If yes, build an app.
6. How will people find it? Search and shared links favour the web. An existing audience you can direct to a store makes an app easier to launch.
7. What will people pay for? Digital subscriptions sold inside an iPhone app fall under Apple's in-app purchase rules. Real-world services do not.
8. Who uses which part? If office staff and field staff do different jobs, you may need a web app for one and a mobile app for the other.

Typical outcomes:

• Mostly desk use, found through search: a responsive web app.
• Repeat use on phones, notifications helpful but not critical: a PWA, with an app later if usage justifies it.
• Frequent use on the move, with push, camera, location or offline entry at the core: an app for both stores, with the technology chosen to fit the scope.
• A premium product for one platform, or heavy use of hardware: native.

Build Hive, a construction platform we built for a UK company, shows the combined route. The web platform, live at build-hive.co.uk, covers quotes, purchase orders, suppliers and reports for the office. The same platform also has native iOS and Android apps for people on site, with GPS clock-in, the camera and push notifications. Both use one back end.

Whatever you choose, keep the back end separate from the front end, and add the second platform when usage shows you need it. Our mobile app development page describes how we approach apps.

Frequently asked questions

Is a PWA cheaper than a mobile app?

Usually, because it is one web codebase with no store accounts, review cycles or store commission. It can cost more in the long run if you later need features iPhone browsers do not support and have to build an app anyway.

Can a PWA send push notifications on iPhone?

Yes, from iOS 16.4, but only after the user has added it to the Home Screen and granted permission by tapping a button. A site open in Safari cannot receive web push.

Can I put a web app in the App Store?

You can package it, but Apple's guideline 4.2 requires an app to offer more than a repackaged website. It needs app-like features, content and interface to pass review.

Do app stores take a cut of every payment?

No. Apple requires in-app purchase for digital features and subscriptions, but physical goods and real-world services must use other methods, such as Apple Pay or card entry, without App Store commission.

Should I build for iPhone or Android first?

Look at what your users carry. If you need both and one codebase fits the scope, a cross-platform app serves both stores; otherwise start with the platform your target users mostly use.

About the author

Arjun Raj is the founder of Digital Architect, a web, app and digital marketing studio founded in 2023 and headquartered in LB Nagar, Hyderabad, with a studio in Bengaluru. The team builds apps and platforms for clients across India, the US, Canada and the UK. Arjun holds a B.Tech in Computer Science and Engineering, specialising in cybersecurity, from IIT Guwahati. More about Arjun

Not sure whether to start on the web or in the stores? Tell us who will use the product, where and how often, and we will tell you what we would build first. Talk to Digital Architect.