What Is a PWA? Mobile App or Web?

01What Does Progressive Web App Mean?

A progressive web app is an approach that adds app capabilities to an ordinary website. The user opens the site in the browser and, if they like it, adds it to their home screen with one tap. From then on it launches like an app, without an address bar, with its own icon and splash screen.

The word “progressive” in the name is important. The app gains as many capabilities as the browser supports: in an old browser it works like a normal site, while in a modern browser offline mode, notifications and home screen installation come into play. Nobody is left out.

This approach is built on web standards; it is not tied to a specific platform or framework. Any site written with React, Vue or plain JavaScript can be turned into a PWA with the right steps.

02The Three Parts That Make a Site a PWA

Technically, a site needs three core components to count as a PWA. All three are standards, and their official descriptions can be found in sources such as web.dev.

{
  "name": "Sample Store",
  "short_name": "Store",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b5cff",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

HTTPS

PWA features work only over a secure connection. A service worker cannot be registered on a site without an SSL certificate.

Web app manifest

The manifest is a small JSON file that describes the app's name, icons, theme color and how it should open. The browser uses this file to offer adding the app to the home screen.

Service worker

A service worker is a JavaScript file that sits between the browser and the network. It caches pages and files, shows saved content when the connection drops, and manages notifications on supported platforms.

03Benefits of a PWA

The biggest of these benefits is most often felt on the cost side. Instead of two separate mobile apps, two separate maintenance efforts and two separate store processes, you manage a single web project. The factors that really affect the budget are the number of screens, the complexity of offline scenarios and the systems to be connected.

• Single codebase: no separate development for iOS, Android and desktop.
• Store independence: you do not wait for approval to publish an update; the change reaches everyone instantly.
• Low installation friction: users start straight from a link without going to a store.
• Visible in search engines: because the content is a web page, Google can crawl it.
• Lightweight: it usually takes up far less space on a phone than native apps.
• Works offline: even on a weak connection, cached content opens.

04Limits of a PWA

A PWA does not answer every need; for an honest comparison you also need to know its limits.

iOS support is more limited than on Android. Features such as adding to the home screen and notifications have improved over time, but some behaviors still differ, and the install prompt does not appear automatically; the user has to add it from the share menu.

Hardware access is limited too. Basic features such as the camera, location and vibration are available on the web, but for needs like Bluetooth devices, continuous background location tracking or graphics-heavy games, native apps are still ahead.

Finally, there is store visibility. Some users search for apps only in the store. On Android, PWAs can be listed on Google Play using certain methods; on iOS, this route usually requires a native wrapper app.

05Mobile App or Website?

This question is really a decision among three options: a mobile-responsive website, a PWA and a native mobile app. The table below summarizes the differences.

06Which Businesses Is a PWA Right For?

A PWA shines most where users come back often but do not want to download a separate app. For a user whose phone storage is full and who does not want to install yet another app, a lightweight experience that opens from a link and is added to the home screen is often the shortest path.

• E-commerce stores: a fast-opening store that sits on the home screen for repeat customers.
• Restaurants and cafes: menu and ordering screens that open from the QR code on the table and work without downloading an app.
• Reservations and appointments: quick repeat bookings for a hotel, clinic or hair salon.
• Field teams: technical service or sales teams who fill in forms where the connection is weak.
• Content sites: frequently read content such as news, guides and catalogs.

07What Determines the Cost?

The budget of a PWA project is shaped less by the “app or site” question and more by the details of the scope. There is a big difference between adding a manifest and caching to a simple content site and building a field app that takes orders offline.

The items that affect the budget most are: the number of screens and flows, the complexity of the operations that must work offline, notification scenarios, the systems to be connected such as payments, inventory or reservations, and how original the design will be. On top of these, add the need for maintenance and updates after launch.

When comparing with a native app, do not look only at the initial development cost. Version tracking for two platforms, store updates and device testing are items that recur every year. With a PWA, a significant share of these items is gathered into a single web process; this is often where the real savings appear.

08Before Starting a PWA Project

The code side of a PWA is mostly written in JavaScript; on large projects TypeScript is preferred for type safety. If you wonder how work is divided between the interface and the server, our article on the difference between frontend and backend explains it simply. For those who want to start from the basics, our What is JavaScript article is a good entry point.

1. Fix the mobile experience: a fast, readable, touch-friendly site is the basic requirement.
2. Set a speed target: the Core Web Vitals thresholds (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1) are a good starting benchmark.
3. Define the offline scenario: what should the user be able to see and do when there is no internet?
4. Decide your notification strategy: ask for permission not in the first second, but after you have shown value.
5. Test on real devices: try installation and launch behavior separately, especially on iOS and Android.