Why PWAs Could Ruin Your Business — and When They're the Right Call in 2026

Why Fora Soft wrote this PWA playbook

The provocative title in this article is on purpose. PWAs are a real, mature technology that has shipped real businesses — Twitter Lite, Pinterest, Uber, Starbucks, Tinder. They are not a scam, and they are not dead. But picking PWA for the wrong product is one of the most expensive default decisions we see founders make. The cost shows up not at launch but six to nine months later, when the founder discovers App Store discovery does not work, push notifications never deliver on iOS, and the IAP path their monetisation depended on is impossible.

Fora Soft has been building software since 2005 across native iOS, native Android, React Native, Flutter, Capacitor, and pure web. We deliver PWAs when they fit; we deliver native when they fit. The point of this article is to put the decision in writing so you can pick the right path on purpose, not by accident.

Concrete proof: across our portfolio — Perspire.tv (live fitness streaming, native + web), CirrusMED (HIPAA telehealth), BrainCert (WebRTC classroom) — the platform call was different in each case, and the engineering economics flowed from that call. We will help you make the same kind of call for your product.

What a PWA actually is in 2026

A Progressive Web App is a web application with three specific technical requirements: HTTPS, a Web App Manifest (a JSON file describing the app to the browser), and a Service Worker (a JavaScript proxy that runs in the background, enabling offline behaviour, caching, and push notifications). Modern PWAs install to the home screen on Android and iOS with a single tap, run in their own window without browser chrome, and behave for most users like a native app.

In 2026 every major browser supports the core PWA APIs, and service workers are available to roughly 87% of internet users. iOS Safari is the constraint — it supports PWA push only since iOS 16.4 (March 2023), still does not support Background Sync, has tighter storage quotas than Chrome, and historically has limited what PWAs can do versus native apps. The good news is that Apple supports the basics and the EU DMA fight in 2024 forced Apple to keep PWAs alive on iOS. The bad news is that the iOS PWA experience is still measurably weaker than the Android one.

In short: PWAs are real and mature, but iOS is the gating factor on whether they fit your product. Read on.

The business case FOR PWAs in 2026

Cost. A PWA build runs roughly $25k–$80k in 2026 industry benchmarks. Native iOS plus Android plus web typically runs $80k–$200k+ for the same scope. PWAs come in 30–50% cheaper than a single native platform and 60–70% cheaper than the iOS+Android+web triad.

Single codebase, instant updates. One JavaScript codebase serves iOS, Android, desktop web, and mobile web. Updates deploy in minutes; no App Store review cycle. For a product still discovering its shape, the iteration speed is meaningful.

Lower acquisition friction. A PWA installs from a URL with one tap. Native requires the user to leave your context, navigate the app store, search, install, and return. The drop-off in that flow is large enough to be a marketing line item.

SEO and indexability. Google indexes PWAs and surfaces them in organic search. Native apps do not appear there. For content-driven products (news, e-commerce, blogs), the SEO traffic alone often pays back the build.

Real measured impact. Twitter Lite reported a 75% increase in tweets sent and 65% more pages per session after launching their PWA, with a 20% drop in bounce rate. Pinterest measured a 40% jump in time-spent and a 60% lift in core engagement. Starbucks doubled daily active users and shipped a PWA 99.84% smaller than the iOS app. Tinder cut load times from 11.91 to 4.69 seconds and shipped a PWA 90% smaller than the native Android app. Uber’s core PWA is 50KB gzipped and loads in under three seconds on 2G networks. The success cases exist.

The business risks AGAINST PWAs — what the title is about

1. iOS Safari constraints. Apple has historically restricted PWA capabilities to protect App Store revenue. Push notifications arrived only with iOS 16.4 (2023). Background Sync, Periodic Background Sync, and Background Fetch are not supported on iOS — meaning your PWA cannot reliably refresh data while the user is not in it. Storage quotas are tighter than Chrome, and the cache may purge after periods of inactivity.

2. Lost App Store discovery. Users browse app stores with intent. They search categories, scan reviews, install. PWAs are absent from that channel entirely. For a product whose growth depends on app-store ranking or category visibility, losing that channel is losing the business model.

3. No native APIs. Bluetooth, NFC (limited), HealthKit, ARKit, advanced camera controls, on-device ML inference, secure enclave biometric auth. Apple declined to implement 16 web APIs in Safari in 2020, including Web Bluetooth, Web NFC, WebUSB, Web Serial, and Web MIDI. If your product needs any of these, PWA is the wrong call.

4. Monetisation friction. No App Store IAP. No native subscription management. Apple Pay works through the Payment Request API, but the seamless one-tap purchase that converts on native is harder on web. The "you save the 15–30% Apple cut" argument is true; the "your conversion rate may be 30–50% lower" counter-argument is also true. Run the math both ways.

5. Push notification weakness on iOS. Even with iOS 16.4+, push works only for PWAs the user has manually added to the home screen, with permission triggered by user interaction. Many users never add the PWA. The retention curve on iOS PWAs trails native by 20–40% on engagement-heavy products.

6. Performance ceiling. Heavy real-time video, AR, advanced 3D graphics, on-device AI inference, multi-stream WebRTC at scale — native still wins. PWAs are fast for content; they hit a ceiling on compute-heavy or media-heavy workloads.

7. Trust signal gap. A meaningful slice of users distrust "websites in disguise". The App Store badge conveys legitimacy that a PWA banner does not. For B2C consumer products, the perception cost is real.

8. Apple-dependency risk. In February 2024, Apple announced plans to remove Home Screen PWA support in the EU under the DMA. The European Commission opened an investigation; within two weeks Apple reversed. The lesson: PWAs on iOS exist on Apple’s sufferance, and Apple has demonstrated it will withdraw or restrict support when commercial incentives line up. Plan for the constraint, do not hope it disappears.

PWA vs native vs hybrid — the practical comparison

A condensed view of the trade-offs across build cost, capabilities, distribution, and ongoing economics.

When PWA is the right call

Pick PWA when most of these conditions hold simultaneously.

Content-driven products. News, blogs, e-commerce browsing. Indexability and link-sharing are growth channels; the App Store would not have been the primary acquisition path anyway.

B2B internal tools. Users come from email, Slack, or a corporate intranet. Onboarding via link beats onboarding via app-store install. Revenue is from contracts, not in-app purchases.

Emerging-market consumer apps. Low-end devices, limited storage, expensive data plans. A 50KB PWA shipped in three seconds on 2G beats a 50MB native install.

Low-engagement products. Users return weekly or less. Push retention is not the lifeline; the URL bookmark is enough.

Products that need instant updates. A/B testing daily, fixing a critical bug at 2 AM, shipping a marketing change in minutes. App Store review cycles are the wrong fit.

When PWA is the wrong call

Pick native (or hybrid) when most of these conditions hold simultaneously.

Daily-engagement consumer apps. Push, retention, and IAP are the unit-economics levers. PWA on iOS gives you a weakened version of all three.

Native API dependencies. Camera filters, Bluetooth pairing, on-device ML, ARKit, HealthKit. These are not available on PWA; they will not become available on PWA in the timeframe of your launch.

Subscription monetisation without a strong web flow. If your subscription depends on App Store IAP or you cannot run a credible web checkout, PWA constrains your monetisation to the point of breaking the model.

Real-time video, audio, AR. Multi-stream WebRTC at scale, AR overlays, on-device AI inference. Native still wins on latency, codec control, and battery.

App Store discovery as a growth channel. If category rankings, store search, and editorial features are how you acquire users, you cannot give up the App Store presence. PWA is not the path.

Hybrid approaches — PWA plus native from a shared codebase

The under-used third path: combine a PWA with a thin native shell so you get the cost benefits of one codebase plus the App Store presence and native APIs where they matter.

Trusted Web Activities (TWA). Google Play accepts PWAs wrapped in a TWA — effectively a Chrome shell that opens your PWA. Digital Asset Links verify trust between the Android app and your domain. Listed in the Play Store, installable as an Android app, but reuses the PWA codebase. The cheapest way to get App Store presence without doubling the build.

Capacitor. Wraps a web app in a native iOS or Android shell, with a plugin system for native APIs (camera, push, biometrics). Used by Ionic apps. Lets you ship one codebase to the App Store and Play Store with selective native capability.

React Native and Flutter. Cross-platform native frameworks with shared business logic and platform-specific UI. More expensive than PWA or Capacitor; less expensive than two separate native teams. The 2026 default for cross-platform consumer apps.

Kotlin Multiplatform (KMP). The newest entrant, with traction in 2025–2026. Shares Kotlin business logic between iOS and Android; UI stays platform-native (SwiftUI on iOS, Jetpack Compose on Android). Right when the UI matters and the business logic is heavy.

Cost and maintenance — the twelve-month math

Pure PWA. Build $25k–$80k. Annual maintenance ~15% of build — roughly $4–$12k. No App Store review tax. Single team, single repo, single deployment pipeline. Lowest TCO for the right product profile.

Native iOS plus Android plus web. Build $80k–$200k+. Annual maintenance 20–25% of build — roughly $16–$50k. Three teams or one team across three stacks; the integration tax of keeping the platforms in feature parity is real and ongoing.

Hybrid (React Native, Flutter, Capacitor). Build $60k–$150k. Annual maintenance 15–25% of build — roughly $9–$37k. Compresses dev time by 30–40%, but does not eliminate platform-specific QA, App Store review cycles, or device-specific bugs.

The honest take. The PWA cost advantage is real but not infinite. Hybrid is often a better value than people assume. Native is expensive, but if your product needs it, the alternatives cost more in lost growth than they save in build budget. Run the math against your specific monetisation model and growth channels — the right answer is rarely "default to whatever everyone else picked".

Five PWA pitfalls we see most often

1. Service worker bugs and cache invalidation. A bad service worker can serve stale content forever. Retrofitting cache strategy is painful; design the update mechanism on day one. Use Workbox, set explicit cache versions, and ship a "force update" path.

2. iOS storage purge. Service worker cache may disappear after periods of inactivity on iOS. Do not assume cache is durable; assume it is best-effort. Critical state belongs on your backend.

3. Install prompt friction. On iOS the user must manually share-sheet to "Add to Home Screen". Most users never do. The PWA install funnel needs explicit education and timing — the prompt that converts is not generic.

4. Push notification UX. iOS push works only after install. Permission must be requested via user interaction, not on first load. The "subscribe to notifications" flow that works for Android does not work for iOS without re-design.

5. The "not a real app" perception. A measurable slice of users distrust PWAs as websites. Visual cues — standalone window, icon, splash screen, app-like navigation — matter more than they would for a native app. Underinvest in this and you bleed users at the install moment.

Mini case — how Fora Soft picks the platform

A useful proof-of-pattern. Three real engagements, three different platform calls.

Perspire.tv — native plus web. Live fitness streaming with low-latency two-way coaching, push-driven retention, subscription monetisation. We built native iOS and Android plus a complementary web experience. PWA was the wrong call — the workload (RTC, push, IAP) needed native control.

BrainCert — web-first. Virtual classroom for institutions; users come from email links and LMS embeds; instructor and student workflows are content- and form-heavy. The web layer is the primary product. The platform call was web-first with native shells where they earned their cost — a hybrid path that fit the workload.

CirrusMED — native, with web companion. HIPAA telehealth needs strong device-level security, biometric auth, secure local storage, and reliable push for appointment reminders. Native was the call. PWA would have failed compliance review on the storage and biometric requirements alone. Want a similar platform call for your product?

A platform decision framework in five questions

Q1. Where do users come from? If from links (email, Slack, search), PWA wins on friction. If from app-store search, native wins on discovery.

Q2. How does monetisation work? Web subscription, contracts, or B2B billing → PWA viable. App Store IAP, freemium with paywalls, in-app currency → native required.

Q3. Are native APIs in scope? Camera, AR, Bluetooth, HealthKit, advanced ML, biometric auth, NFC. If yes, PWA is out.

Q4. How does retention work? Push-driven daily engagement → native. Weekly-or-less link-driven engagement → PWA viable.

Q5. What is the budget reality? If you can only fund one of (web, iOS, Android), PWA gets you all three. If you can fund all three, you should compare PWA vs hybrid vs native on the workload, not on the cost alone.

Frequently asked questions

What to Read Next

Ready to make the platform call deliberately?

PWAs are not a scam and they are not dead. They are also not the right answer for every product. The decision is not religion; it is workload-shaped: where users come from, how monetisation works, which native APIs are required, how retention is driven, and where the budget lives. The companies that win on PWA picked it on purpose. The companies that lose on PWA picked it because it was cheaper, and discovered six months later that "cheaper" cost them the App Store discovery, the push retention, or the IAP path their business model needed.

The most useful next step is a 30-minute platform call with senior engineers who have shipped on every stack. Bring your scope, your monetisation model, and your growth channels. We’ll come back with the right call — PWA, native, or hybrid — and the math behind it. The point is to make the decision deliberately, with evidence, before you sign anything.