Web app vs mobile app vs PWA: what to build first

Build a web app first if people find you through search or links, use the product at a desk, or come back less than weekly. Build a mobile app first if the main feature needs Bluetooth, background location or a widget, or daily use depends on iPhone notifications. A PWA (progressive web app) is a web app people can install. On an iPhone it gets push notifications only after the user adds it to the Home Screen, which iOS has allowed since 16.4 (WebKit). Below: web app vs mobile app vs PWA compared, and what we ask before choosing.

What is the difference between a web app, a mobile app and a PWA?

The difference is how people get the software and what it's allowed to do on their phone.

• A web app is software that runs in a browser at a web address. Nobody installs it, everyone uses the same version, and a change is live as soon as you deploy it. Customer portals, booking systems and dashboards are web apps.
• A mobile app is a program people download from the App Store or Google Play. It's written twice, in Swift for iOS and Kotlin for Android, or once in a cross-platform framework such as Flutter. Every release goes through store review.
• A PWA is a web app with a manifest file (its name, icons and how it opens) and usually a service worker (a script that can cache pages and run when the app isn't open). MDN defines it as "an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app" (MDN, updated 31 August 2026).

A website is a fourth thing: pages to read, such as a company site or a blog. If that's what you need, the choice is between site platforms, which we cover in Next.js or WordPress for a business website.

Web app vs mobile app vs PWA: how do they compare?

They differ most in how people find and install them, what they can do on an iPhone, and how quickly a change reaches users. Everything in the table was checked on 1 November 2026.

Sources: WebKit for iPhone push, caniuse for Web Bluetooth, the store fee pages linked in the payments section below for the 15%, Apple's enrollment page and Google's Play Console help for the account fees, and our launch timeline for both stores for the 4 weeks.

PWA vs native app: what can a PWA do on an iPhone?

More than it could before 2023, but the user has to do the installing, and in most countries every iPhone browser runs on Apple's engine.

• Push and badges. Since iOS 16.4, Home Screen web apps can receive Web Push and set a badge count on their icon. The permission request has to come "in response to direct user interaction", such as tapping a subscribe button (WebKit, 16 February 2023). Apple's web push documentation offers it to "Home Screen web apps in iOS 16.4 or later" and to ordinary webpages only in Safari on the Mac, so on an iPhone a site open in a Safari tab gets no push.
• Installing. iOS and iPadOS show no browser prompt to install a PWA (web.dev). People tap Share, then Add to Home Screen. Since iOS 26, "every website added to the Home Screen opens as a web app" by default (WebKit, Safari 26.0, 15 September 2025), and since iOS 16.4 other browsers can offer Add to Home Screen too.
• One engine. Apple's guideline 2.5.6 says apps that browse the web "must use the appropriate WebKit framework and WebKit JavaScript", with entitlements for other engines offered in the EU and Japan (App Review Guidelines). Everywhere else, Chrome on an iPhone runs on the same engine as Safari and has the same limits.
• Hardware. Web Bluetooth and Web NFC are both "Not supported" in Safari on iOS (Web Bluetooth and Web NFC on caniuse, checked 1 November 2026). If your product talks to a Bluetooth device or reads NFC tags, iPhone users need an app.

Android is friendlier. Chrome offers to install a site once it's served over HTTPS, has a manifest with a name, a 192px and a 512px icon, a start URL and an app-style display mode, and the visitor has tapped the page and spent 30 seconds on it (web.dev install criteria, updated 19 September 2024).

The site you're reading shows the other side. zoftaa.com has a manifest, but its display mode is browser, which isn't one of the 4 modes Chrome accepts, so Chrome never shows its install prompt for this site. For a studio's website that's right: nobody needs it on a home screen or offline.

Can a PWA go on the App Store or Google Play?

On Google Play, yes. On the App Store, only inside a native app that does more than show the site.

• Google Play. A Trusted Web Activity is a way to open "your web-app content such as your Progressive Web App (PWA) from your Android app", full screen in the user's browser. Digital Asset Links prove that the app and the site "come from the same developer" (Android docs, updated 26 February 2026), and a command-line tool called Bubblewrap generates the project. It's still a Play app: the same review, the same forms and, on a new personal account, the same 14-day closed test.
• App Store. The route web.dev lists is "WKWebView and App-Bound Domains", meaning a native app that shows your web content. This is where wrapped sites get stuck. Guideline 4.2 says "Your app should include features, content, and UI that elevate it beyond a repackaged website", and "If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." Apple's App Review page lists web clippings among common problems: "Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."

So if being in the App Store matters to your business, plan an app. A wrapper with a few native extras depends on a reviewer agreeing that it's "app-like".

The questions we ask before choosing

These are the questions we work through on a scope call before recommending any of the three. The first six are about your users, the last two about your business.

One more question has the same answer whichever you pick: which web pages will you need anyway? That one, and three from the table, get a section each below.

How often will the product change in the first 3 months?

If it's weekly, the web is cheaper to change. On this site a change is a commit, a build and a deploy, and every visitor has it on their next page load. A mobile release goes through review, and the old version keeps running on phones that haven't updated.

That second point has a cost. The rule we follow in the backends behind our apps is that API changes are additive: new fields are optional with defaults, and old paths stay alive as aliases, so the older builds still on people's phones keep working. A web app has one live version, so its pages and its API can change together. For a product still finding its shape, that's a real saving.

Which phones do your users carry?

It depends heavily on the market. StatCounter's figures measure mobile web page views, so read them as browsing share by platform (October 2026, checked 1 November 2026):

For an audience that's mostly on Android, a PWA comes close to an app: Chrome offers the install, and push works without a store. For an audience with many iPhones and a product that lives on notifications, a PWA relies on each person finding Add to Home Screen by hand. Your own analytics beat these numbers once you have them.

How will you take money?

Inside an iOS app, unlocking "features or functionality", including subscriptions and premium content, "must use in-app purchase" (guideline 3.1.1). Apple takes 15% on paid apps and In-App Purchases for new developers and for those who made up to 1 million USD in proceeds the year before (Small Business Program). One exception: guideline 3.1.1(a) now lets apps on the United States storefront include buttons and links to other ways to pay.

On Google Play, purchases by users in the US, the UK and the EEA have followed a new table since 30 June 2026, and in Australia and Japan since 30 September: 10% plus a 5% billing fee on the first $1M a developer earns each year, and the same 10% plus 5% on subscriptions above that. Elsewhere, developers in Google's 15% tier pay 15% on the first $1M, and subscriptions are 15% at any level (Play service fees). Apple's and Google's pages were checked on 1 November 2026.

A web app takes cards through a processor. Stripe's US price is "2.9% + 30¢" per successful domestic card payment (Stripe pricing, checked 1 November 2026).

Example: a $10 monthly subscription. Through Apple at 15%, the fee is $1.50. Google Play's new rate for a US subscriber, 10% plus the 5% billing fee, comes to the same $1.50. Through Stripe in the US, it's 2.9% of $10 plus 30 cents, so $0.59. At $3 a month the gap narrows: $0.45 against $0.39. The higher the price, the more the store's share decides the question. In our apps, subscriptions go through store billing, with RevenueCat on top to track who has paid.

Which web pages will you need anyway?

Some, even for an app that lives only on phones. Every app we've shipped on Google Play needed a privacy policy on the web: Google says "You must link to a privacy policy on your store listing and within your app", on an "active, publicly accessible URL" that's a "standard, non-editable webpage" (Prepare your app for review). Apple's guideline 5.1.1(i) asks for the same link in App Store Connect and inside the app. If users can sign up, Google also wants an in-app way to delete the account and "a web link resource where users can request app account deletion", which has to name the app or developer as it appears on the store listing (account deletion requirements). Google accepts a highlighted section of the privacy policy. In our releases we give it a page of its own, with the steps and a list of what's deleted and what's kept. Then there's the admin panel your staff use to manage users and content, which is a web app in its own right.

A bigger web part appears when strangers must open what users make without installing anything. In a Flutter product we're building, people make a page in the app that anyone can open from a link. So the page is drawn twice, in Flutter for the preview inside the app and in the browser for visitors, from one written set of rules for spacing, fonts and contrast, because two renderers drift apart otherwise. Even the contrast check is the same maths in Dart and in JavaScript: if text falls below a 3:1 contrast ratio against its background, both switch it to near-black or white. We also learned that link previews in chat apps and social networks read the HTML the server sends, so a page that builds itself in JavaScript gets a preview with no title or image. Fixing that needs server rendering.

Can one codebase give you all three?

Partly. Flutter builds Android, iOS and web apps from the same Dart code, and its web FAQ calls it suited to "Progressive Web Apps", "Single Page Apps" and "Existing Flutter mobile apps". The same FAQ says Flutter "is not suitable for static websites with text-rich flow-based content", and that its output "doesn't align with what search engines need to properly index" (Flutter web FAQ, updated 24 October 2026). For landing, marketing and help pages it suggests search-friendly HTML, or Jaspr, a Dart framework that outputs ordinary web pages.

So one Flutter codebase can cover the logged-in app on phones and in the browser, but the pages people find through search are a separate build. If the app also needs features Flutter can't reach, we list where we've used Kotlin and C++ in Flutter or native?.

When is each one the wrong first build?

Each has a case where it costs more than it gives back.

• A mobile app is the wrong first build when you don't yet know whether people want the product. You open two store accounts, fill in the store forms and, on a new personal Play account, go through about 4 weeks of release steps before a stranger can install it, and every fix after that waits for review. You also need a Mac, your own or a cloud build service, since App Store uploads "must be built with Xcode 26 or later" (Apple, since 28 April 2026).
• A PWA is the wrong choice when most users are on iPhones and the product depends on notifications, because each person has to install it by hand before the first push can arrive. It's also the wrong choice for Bluetooth devices or NFC tags that iPhone users must reach.
• A web app is the wrong first build when the main task happens away from a desk, many times a day, with the phone in a pocket between uses. A web page can't track location in the background, and it has no icon on the home screen unless the user adds one.

What drives the cost is different for each. For a web app, it's the screens, user roles and integrations. A PWA adds offline rules (what's cached, what happens to a form sent with no signal) and testing install and push on real iPhones and Android phones. A mobile app adds the store paperwork, review rounds, a backend that keeps old versions working, and the web pages from the section above.

What we would do

• For a tool people use at work, a portal, a dashboard or a marketplace's back office: a web app in Next.js that works on a phone screen from the first build. That's the core of our web development work.
• For repeat use on phones, an audience that's mostly on Android, and no special hardware: the same web app, made installable as a PWA with a manifest, icons and a service worker for offline forms. Push works on Android straight away and on the iPhones whose owners add it to the Home Screen.
• For a consumer product used daily, with push on iPhones, the camera, Bluetooth or a store listing as part of the plan: a Flutter app for both stores, plus a small web side (a landing page, the privacy policy, the account deletion page and the admin panel). The landing page stays in HTML, for the search reasons Flutter's own FAQ gives.

Whichever comes first, we'd build the backend as an API from day one, so an app added later uses the same one. If you're unsure, start with the web app and watch how people use it on their phones. Daily visits from phones are the sign we'd look for before building an app.

A rule for deciding

Write one sentence: who does the main task, where, and how often. If the answer is at a desk, or less than once a week, build a web app. If it's on a phone every day and needs hardware, background work or iPhone push without asking anyone to install from Safari, build a mobile app. If it's on a phone every day and most of your users carry Android, build the web app as a PWA and add store apps when daily use on phones shows they're worth it. Put the sentence in your brief, and if you'd like a second opinion on it, send it to us or email hello@zoftaa.com.