Progressive Web Apps (PWA) for Business: The Native App Alternative

Many founders and business owners assume that if they want a mobile presence, they must build separate iOS (Swift) and Android (Kotlin) native apps.

Building native mobile apps comes with massive friction: * Double Development Costs: Maintaining two separate mobile codebases plus a web backend. * App Store 30% Tax: Handing over 15% to 30% of your digital subscription revenue to Apple and Google. * Gatekeeper Review Delays: Waiting 3 to 7 days for App Store approval just to push a minor bug fix.

For 80% of business applications, Progressive Web Apps (PWAs) offer a faster, cost-effective alternative.

That "80%" deserves qualification, though. A PWA is the right answer for a specific and large category of business software — and genuinely the wrong answer for another category, mostly defined by hardware access and iOS behaviour. This guide covers both sides so you can place your product correctly.

What a Modern PWA Can Do

• Installable on Home Screen: Prompts users to "Add to Home Screen" with custom app icons.
• Offline Caching: Service Workers cache data and assets so field workers can use the app without internet connection.
• Web Push Notifications: Re-engage users on desktop and mobile with real-time alerts.
• Instant Updates: Deploy a fix to your server, and all users get the update immediately upon refresh.

What It Cannot Do (Yet)

Anyone recommending a PWA without mentioning these is selling, not advising:

None of those are fatal for a business application. Several of them are fatal for a consumer app or a field-service app with hard offline requirements.

Install Rates: The Number Nobody Wants to Say Out Loud

A PWA only delivers app-like value if it is actually installed, and install rates vary enormously:

• Android (Chrome): the install prompt is available, and 20–40% of engaged users install when asked at the right moment. Timing matters more than anything else — prompt after a completed task, never on the first page view.
• iOS (Safari): with no prompt and a manual install flow, expect single-digit percentages unless you actively walk users through it with an illustrated one-pager or a short video.

The practical implication: build a convincing install path into onboarding, show the actual iOS Share icon in your instructions, and treat installation as a product metric with a target. A PWA that nobody installs is a website with extra complexity.

The Money Argument, Properly Calibrated

The "30% tax" is real but narrower than many articles imply:

• Apple and Google take 15–30% of digital goods sold inside native apps.
• Physical goods and services (most B2B offerings) are generally exempt.
• Web-based payments avoid the commission entirely — though if you sell digital content inside a native app, you are still bound by store rules.
• EU regulation under the Digital Markets Act has opened alternative payment routes in Europe, but the situation is still evolving and jurisdiction-specific.

So the correct comparison is not simply "PWA saves 30%". It is: what share of your revenue is digital, sold in-app, to mobile users whose purchase would otherwise go through a store? For many B2B products that share is small — the real saving is development and maintenance cost.

Cost and Timeline, Side by Side

The wrapper option deserves attention because it resolves the discoverability objection: ship your PWA inside a thin native shell to get store listings and, where permitted, native modules for the handful of features the web cannot reach.

The Technical Stack That Works

For a Nuxt 3 application, the practical setup:

• @vite-pwa/nuxt (Workbox under the hood) for manifest, service worker generation and update prompts.
• Caching strategies per asset class. Precaching icons and the app shell, stale-while-revalidate for API reads that can tolerate staleness, and network-only for anything financial or permission-sensitive. Caching a user's account data in a service worker that survives logout is a real security bug we have seen more than once.
• Versioned service workers with a user-visible update flow. Hiding the update prompt forces users onto a stale build. Show "A new version is available — reload", and force it after a couple of prompts.
• Offline write queue in IndexedDB, replayed on reconnect, with conflict handling and clear status to the user ("3 changes waiting to sync"). Offline reads are easy; offline writes are where projects fail.
• Push infrastructure: VAPID keys, the web-push library server-side, a subscription table per device, and a permission request triggered only after the user has taken a relevant action. Prompting for notifications on first load produces a permanent denial in most browsers.
• A real-device test matrix. Simulate nothing critical: install flow, offline reads, offline writes, push delivery and update behaviour must be checked on a real iPhone and a real mid-range Android.

When Native Is Still the Right Call

Choose native (or a native wrapper) when any of these apply:

• The app depends on hardware the browser cannot reach reliably — background location, Bluetooth peripherals, NFC, sustained camera processing.
• Offline is the product, not a convenience. A field inspection app that must work for eight hours with no signal needs native storage and sync semantics.
• You sell digital content in-app and store presence drives volume — consumer subscriptions, premium unlocks.
• Discoverability requires store browsing, and your acquisition depends on being found in the App Store.
• Push is the primary channel. iOS web push is improving but remains behind native in reliability and diagnostic tooling.
• Users expect it. In some consumer categories, "download our app" is itself the trust signal.

Note that these can coexist with a PWA strategy: many of our clients run a PWA as the product for desktop and Android, and a wrapped native build for the iOS-heavy segments where installation friction costs more than the wrapper.

Push Notifications in Practice

Push is the feature most often oversold on PWA checklists. What actually works:

• Permission is a one-shot decision. If a user denies it, you generally cannot ask again. Request permission only after the user has taken a meaningful action — completed a task, enabled an alert preference, or subscribed to something. Apps that prompt on first load see denial rates above 80%.
• Android/Chrome permission acceptance sits around 50–70% when prompted contextually; iOS web push, still newer and dependent on installation, is lower.
• Every notification must have a reason to exist. Reminders people asked for, status changes they are waiting on, and time-sensitive alerts work. Marketing blasts deplete the channel quickly, and users revoke permission rather than quietly ignoring it.
• Include a deep link. A notification that opens the app home screen instead of the relevant record wastes the click.
• Support quiet hours and per-category preferences, and store subscriptions per device so a user with a laptop and two phones can manage them separately.
• Clean up dead subscriptions. Browsers return specific errors for expired endpoints; deleting them keeps delivery metrics honest.

For an internal B2B tool, the highest-value notifications are usually "your export is ready", "an approval is waiting on you" and "a background job failed" — low volume, high relevance.

Choose With a Decision Table

The Real Deciding Question

Ask: does my product need something the browser cannot do, or distribution that only a store provides? If the answer is no, a PWA gets you to market faster, cheaper, with one codebase, instant updates and no store review queue — and it becomes installable by exactly the users who care enough to want that.

If the answer is yes, build native for the part that needs it and keep the web app for everything else. One codebase is a genuine advantage, but it is not worth compromising the product's core capability to preserve it.

Related reading: Website vs web app covers the product-shape question first; SSR vs SPA covers rendering for the web half; and real-time with WebSockets covers the feature that most often pushes teams toward native. Ready to build a unified web and mobile application on a single codebase? Contact KEHEM IT.

Weighing a PWA against a native app? Tell us what your users need offline and we will tell you which one is worth building.