What Is a Progressive Web App?
A Progressive Web App (PWA) is a website built with modern web standards that behaves like an installed app. It runs in the browser, but with a service worker it can cache assets for offline use, receive push notifications, update in the background, and launch full-screen from the Home Screen — no App Store required. The term was coined by Google engineer Alex Russell in 2015; a decade later, PWAs have become a mature, cross-platform delivery model.
In 2026, the core PWA stack is widely supported: service workers, the Web App Manifest, Web Push, the Badging API, installability prompts, and a large surface of device APIs including camera, geolocation, clipboard, and payments. Chromium browsers (Chrome, Edge, Brave, Arc), Safari 17+, and Firefox all implement the baseline — with Apple continuing to close historical gaps each year. Learn more in the web.dev PWA guide.
- Installable: Users can add the app to Home Screen, taskbar, or app drawer without an app store
- Offline-capable: Service workers cache shell, data, and assets for offline or flaky networks
- Linkable: Every screen is a URL — shareable, crawlable, indexable by search engines
- Discoverable: PWAs rank in Google Search; native apps only appear via App Store SEO
- Updatable instantly: Ship code without waiting for App Store review cycles
- Single codebase: One product reaches web, Android, iOS, and desktop from the same repo
High-profile PWAs include Starbucks, Twitter/X Lite, Pinterest, Uber, Spotify Web, Tinder, and the new Figma web editor — each reporting significant gains in engagement, conversion, or load time after the switch. At Frenchy Digital, we've shipped PWAs for e-commerce, SaaS dashboards, and marketing sites where instant access and SEO mattered more than native API depth.
What Is a Native App?
A native app is software built specifically for a single operating system using that OS's first-party SDKs — Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. Native apps are distributed through the App Store or Google Play, installed locally, and have direct access to every hardware and OS capability the platform exposes.
Cross-platform frameworks like React Native and Flutter compile to native binaries as well — they ship through the same app stores, use the same hardware APIs, and look native to the end user. In this article we group React Native and Flutter under "native" since they share the native distribution and capability model, even though they use shared JavaScript or Dart codebases.
- Full hardware access: camera, biometrics, NFC, Bluetooth, ARKit, HealthKit, sensors
- Background execution: location tracking, audio, downloads, silent push processing
- App Store distribution: billing, subscriptions, discovery, trust signals, parental controls
- Best-in-class performance: direct GPU access, native rendering, 120Hz animations
- Deep OS integration: widgets, Siri shortcuts, Live Activities, Dynamic Island, App Clips
- Offline-first by default: the binary is already on-device; no network required to launch
Native is still the right answer when your product lives in hardware — games, AR, fitness wearables, mobile banking, telemedicine, and anything that requires biometric trust or background sensor capture. For the full tradeoff map on native stacks specifically, see our Mobile App Development Guide and iOS App Development in Los Angeles.
Capabilities Comparison: What Each Can Do in 2026
The capability gap between PWA and native has narrowed dramatically, but it hasn't closed. Here's the honest 2026 scorecard across the APIs that matter most for product teams:
| Capability | PWA (Android) | PWA (iOS 17+) | Native |
|---|---|---|---|
| Offline support | Full — Service Worker | Full — Service Worker | Full — bundled on device |
| Push notifications | Full Web Push | Web Push (Home Screen only) | Full, rich, interactive |
| Background sync | Full Background Sync API | Not supported | Full background tasks |
| Camera & microphone | getUserMedia | getUserMedia | Full AVFoundation / CameraX |
| Biometrics (Face ID / Touch ID) | WebAuthn (limited UX) | WebAuthn (passkeys) | Full LocalAuthentication / BiometricPrompt |
| File system access | File System Access API | Read-only, limited | Full native file APIs |
| Payments | Payment Request + Apple/Google Pay | Payment Request + Apple Pay | In-app purchase + native wallets |
| AR / VR | WebXR (experimental) | Not supported | ARKit / ARCore / Vision Pro |
| Bluetooth & NFC | Web Bluetooth, Web NFC | Not supported | Full CoreBluetooth / CoreNFC |
| Background location | Limited — visible only | Not supported | Full with permission |
The pattern is consistent: Chromium-based Android PWAs rival native for most use cases. iOS PWAs have caught up on the basics (installability, Web Push, camera) but still lag on background execution and hardware APIs. Native remains the only option for AR, NFC writing, Bluetooth device control, and apps that need to run meaningful work while the screen is off.
Ask "what exactly does this app need to do when the user isn't looking at it?" If the answer is anything meaningful — tracking, syncing, listening for a sensor — you are in native territory. If the answer is "nothing," a PWA will take you further for less money.
— Frenchy Digital Engineering
Performance Comparison: Benchmarks That Matter
Raw performance is where native traditionally dominated — and where modern PWAs have surprised skeptics. We benchmarked a representative e-commerce product as a React Native native build and as a Next.js PWA with service-worker caching, running on identical iPhone 15 and Pixel 8 devices.
| Benchmark | Native (React Native) | PWA (Next.js + SW) | Winner |
|---|---|---|---|
| First launch (cold) | 180-260 ms | 600-1100 ms | Native |
| Return launch (warm) | 90-140 ms | 120-220 ms | Native (narrow) |
| Time to Interactive (first visit) | N/A — pre-installed | 1.2-2.4 s | N/A |
| Scroll / animation FPS | 60-120 fps | 58-120 fps | Tie |
| Network-bound API call | 380 ms | 390 ms | Tie |
| Memory footprint | 80-140 MB | 35-70 MB | PWA |
| Binary / install size | 45-80 MB | 0.5-3 MB (cached) | PWA |
| Offline cached page load | Instant | Instant (service worker) | Tie |
- Native wins cold-start by ~400 ms because the binary is pre-installed and pre-parsed
- PWAs win memory and install size — often 20x smaller than the equivalent native binary
- Animation and scroll performance are effectively a tie on modern hardware
- For network-bound UX (most CRUD apps), the backend dominates — stack choice is irrelevant
- Service worker caching can make repeat PWA visits feel faster than native for content pages
The practical implication: if your app's hot path is "user taps icon → sees fresh content in under a second," native has a measurable edge. If the hot path is "user arrives from a Google search or a shared link," a PWA is faster end-to-end because there's no install friction. For a deeper dive into web performance, see our Web Development in Los Angeles 2026 guide.
Installation & Discovery: Where Users Actually Find Your App
Capabilities win feature charts; distribution wins businesses. The install and discovery journey is where PWAs and native apps diverge most sharply — and where many decisions are actually made.
| Distribution Channel | PWA | Native App |
|---|---|---|
| Google Search (web) | Yes — first-class SEO, linkable pages | No — only App Store pages indexed |
| Apple App Store | No (pure PWA) — install via Safari Share Sheet | Yes — full listing, reviews, rankings |
| Google Play Store | Yes — via Trusted Web Activity (TWA) wrapper | Yes — native APK / AAB |
| Social share link | Opens instantly in browser — no install | Deep link may fail if not installed |
| QR code / printed media | Opens instantly | Sends to App Store, adds friction |
| Email / SMS campaign | One tap — full experience | Tap → Store → Install → Open |
| Install friction | 1 tap (Home Screen add) | 3-5 taps + download + permissions |
| Update delivery | Instant (next page load) | Store review + user-approved update |
Install friction is the hidden tax of native. Industry data from Think with Google shows that every additional step in the install funnel loses 20-30% of users. PWAs skip the store entirely — a user clicking a Google result is already using your product in under two seconds. This is why content, commerce, and media brands increasingly lead with PWA and use native apps for their most engaged, high-LTV segment.
- App Store SEO (ASO) reaches users already searching the App Store — a narrow funnel
- Web SEO reaches users searching Google — the widest top-of-funnel in digital
- PWAs can use both: the web version indexes in Google, a TWA wrapper lists in Play
- On iOS, brands that need App Store presence must ship a native or wrapped app
- Shared links to a PWA work for every user — no 'You need the app' dead-ends
iOS PWA Limitations in 2026: The Honest Picture
Apple has improved PWA support meaningfully — Web Push arrived in iOS 16.4, Home Screen installs became first-class in iOS 17, and passkeys via WebAuthn now work in Safari. But iOS remains the platform where PWA strategies fail, and it's worth being explicit about what still does not work.
Background Sync — Not Supported
Android PWAs can use Background Sync and Periodic Background Sync to queue offline actions and sync when connectivity returns. iOS does not implement either API. If your app needs to capture data offline and reliably upload it later, plan for a native fallback.
Web Bluetooth & Web NFC — Not Supported
Safari does not implement Web Bluetooth or Web NFC. Any product that needs to read an NFC tag, talk to a BLE device (fitness tracker, POS peripheral, smart lock), or write to an RFID chip requires a native iOS app. This is the single biggest blocker for hardware-adjacent PWAs on iOS.
Engine Lock-In
Despite regulatory pressure, every iOS browser still renders through WebKit on non-EU devices. A feature missing from Safari is missing from every iOS browser. "Just use Chrome on iOS" does not unlock additional APIs — Chrome on iOS is a WebKit skin.
Storage Eviction
Safari aggressively evicts PWA storage (IndexedDB, Cache Storage) after roughly 7 days of disuse for non-Home-Screen sites. Home Screen installs are treated more leniently, but iOS still provides less storage durability than Android. Plan for cache loss.
Push Notification Constraints
Web Push on iOS works only for PWAs added to the Home Screen — not for regular Safari tabs. Notification permission must be requested from a user gesture, and some features like notification actions and rich media are more limited than on Android Chrome.
App Store Absence
Apple does not accept pure PWAs in the App Store. Brands that need App Store credibility, featured placement, in-app purchase, or parental control integration must ship a native or wrapped iOS app alongside the PWA.
When to Choose a PWA
A PWA is the right default when discovery, speed of iteration, and cost matter more than hardware depth. The PWA pattern shines for products where the primary job is to display, transact, and communicate — not to sense, record, or integrate with peripherals.
- E-commerce, marketplaces, and D2C storefronts — SEO and instant-cart wins
- Content, news, and media publications — linkability is existential
- SaaS dashboards and admin consoles — desktop-class usage, frequent updates
- Marketing and lead-gen products — lowest install friction wins the funnel
- Event, travel, and booking apps — used briefly, often via shared link
- Internal tools and employee portals — no App Store politics, instant deploys
- MVPs and early-stage products — validate with one codebase before investing in native
Starbucks rebuilt its ordering experience as a PWA and reported doubling daily active users on web; Pinterest's PWA saw core engagements rise 60% while the JavaScript bundle dropped to a fraction of the previous native web app. The Twitter Lite PWA replaced standalone Android apps in emerging markets and cut data usage by 70%. These aren't exotic cases — they are well-instrumented proof that PWAs can outperform native for specific jobs.
When Tinder built a PWA, the new experience loaded in 4.7 seconds on slow 3G — versus 11.9 seconds for the native app's first launch after install. Users spent longer in the PWA and swiped more.
— web.dev Case Studies
When to Choose Native — and the Hybrid Approach
Native is the right call when your product depends on hardware, background execution, App Store distribution, or premium trust. If any of the following describe your roadmap, skip the PWA-only path:
- AR/VR experiences using ARKit, ARCore, or Apple Vision Pro
- Fintech and banking apps requiring biometric vaults and attestation
- Health and wellness apps integrating HealthKit, Apple Watch, or Wear OS
- IoT, BLE, or NFC device control — smart locks, POS peripherals, medical devices
- Apps that need background location, background audio, or silent push processing
- Games and high-performance creative tools requiring Metal/Vulkan-level GPU access
- Products where App Store discovery and in-app purchase economics are core to the business
For these workloads, Frenchy Digital typically builds with React Native when a shared codebase is viable, or pure Swift/SwiftUI and Kotlin when platform-specific excellence is the goal.
The right answer for most mid-to-large brands isn't "PWA or native" — it's both. Ship the PWA as the public front door, and use a native app for the engaged cohort that justifies the App Store investment. The two products share a backend and a design system.
— Frenchy Digital Architecture Team
The hybrid pattern — PWA for the wide funnel, native for the deep funnel — is now the default at most companies shipping serious mobile experiences. A visitor discovers you via Google, engages in the PWA, then installs the native app when they become a power user. The PWA keeps acquisition friction low; the native app keeps retention and monetization high.
How Frenchy Digital Chooses
- Map required capabilities against the 2026 PWA vs native matrix — pick the constraints first
- Weigh distribution strategy: is the user journey starting in Google or the App Store?
- Model 3-year total cost of ownership — maintenance, not build, is where native costs compound
- Default to a PWA for MVPs and marketing surfaces; add native when the cohort and unit economics justify it
- Share backend, design tokens, and analytics across both products from day one
Not Sure Whether You Need a PWA, a Native App, or Both?
Book a free architecture consultation with Frenchy Digital's team in Los Angeles, Paris, and Geneva. We'll map your capabilities, distribution strategy, and total cost of ownership before a single line of code is written.
PWA, Native, or Both?
Frenchy Digital helps you pick the right architecture — and ship it. Get a free consultation with our engineering team in Los Angeles, Paris, and Geneva.
1517 S Bentley Ave Unit 204, Los Angeles CA 90025
