MobileSeptember 19, 20264 min read

PWA or a mobile app: which to choose

In short

For most launches it is smarter to start with a PWA or a web application: no app-store review, instant updates, one codebase — faster and cheaper. A native mobile app is justified when the scenario depends on the phone's capabilities — camera, background geolocation, offline mode, heavy graphics — or when the app stores themselves are an acquisition channel. The right order for a new product is usually: a PWA to verify demand, native once demand is confirmed.

Contents
  1. 01How a PWA differs from a native app
  2. 02When a PWA is enough
  3. 03When you need a native app
  4. 04What about push notifications on iPhone
  5. 05The working strategy: PWA first, native on demand
  6. 06Selection checklist

How a PWA differs from a native app

PWA

  • Progressive web app — a web application that behaves like a mobile one
  • Installs to the phone's home screen, opens without the browser bar
  • Can send notifications and partly works offline
  • Technically it is a website, so it updates instantly and runs on every platform from a single codebase

Native app

  • Written for a specific platform (iOS, Android) or on a cross-platform framework like React Native
  • Distributed through the App Store and Google Play
  • Integrates deeper with the phone
  • Full access to the camera, sensors, background processes, contacts, and the platforms' payment systems
A PWA is installed on the home screen straight from the browser — no App Store or Google Play — and opens without the address bar.

When a PWA is enough

In our experience, many products don't need native at the start — especially in scenarios like these:

  • The scenario is "browse and order": catalogs, appointments, bookings, enquiries, customer accounts. The web does all of this well.
  • The product is at the demand-testing stage: a web MVP launches without store review, and fixes reach users in minutes, not through app review.
  • The audience arrives from search, ads, or messengers: a person clicks a link and uses the product immediately — no "download our app" barrier.
  • Budget and timeline are limited: one codebase instead of two or three is direct savings on development and later maintenance.
  • B2B tools and internal systems: employees don't need a store, they need a link that works on any device.

When you need a native app

Camera, scanning, AR

Examples and details
Try-on features, barcode and document scanners — stable camera work is better native.

Background geolocation

Examples and details
Tracking couriers and field staff does not work reliably on the web.

True offline

Examples and details
Field workers without connectivity and sync-on-reconnect are a native job.

Heavy graphics and computation

Examples and details
Games, video processing, complex animation.

The stores as an acquisition channel

Examples and details
If users search for a solution in the App Store and Google Play, you need to be there.

Platform payment mechanics

Examples and details
Subscriptions via Apple/Google, one-tap Apple Pay inside the app.

What about push notifications on iPhone

For years the main argument against PWAs was "no push on iOS". That is now half-outdated: starting with iOS 16.4, web apps added to the Home Screen can send push notifications.

Product built around notifications

  • A messenger, order tracking, urgent alerts
  • Native is the safer bet

Push as an auxiliary channel

  • "Remind about an abandoned cart"
  • WhatsApp and Telegram notifications complement it
  • In our projects for Kazakhstan-based businesses this channel has worked reliably, and it doesn't depend on the phone's platform

The working strategy: PWA first, native on demand

For a new product the winning sequence is usually:

  1. Web version or PWA

    Launch a web version or PWA.

  2. Demand check

    Verify demand.

  3. Native app

    Only then invest in a native app — already knowing from analytics what people actually use.

The key condition for this strategy: the backend and API are designed for both platforms from the start. Then the native app plugs into a ready server, and the second iteration costs noticeably less than the first. That is exactly how InterLAB architects MVPs: one server, any number of clients.

The reverse order — "two native apps first, then we'll see" — is the most expensive way to learn that the audience would have been fine with the web version.

Selection checklist

Answer five questions:

  • Does the scenario need the phone's hardware (camera, background, offline)?
  • Will users come from the stores or via links?
  • How critical are push notifications?
  • How many platforms are you ready to maintain for the next two years?
  • Is demand verified, or is this the first version?

If most answers favor simplicity — start with a PWA. If the scenario truly depends on the phone — plan for native honestly, from the start.

Tell us about your task — we'll review your request and get back to you

Got a project?
We'll scope and estimate it — for free.

Tell us about the product or the problem. After reviewing the task we'll come back with an architecture, a timeline and a price for the first version.

  • Scope and risks estimated before we start
  • NDA — yours or ours
  • Work starts within a week

Please do not send passwords, access keys or source code through this form — we will agree a safe way to share access separately.

By clicking the button you agree to the processing of your personal data.