PWA vs native app for client portals: what I'd choose again

Every comparison of progressive web apps and native apps you'll find is written for someone building a consumer product. That's the wrong frame for this decision. A client portal isn't competing for downloads in a store — it's a private tool that ten, or fifty, or two hundred specific people are asked to use because you asked them to. That changes which trade-offs matter, and it changes them enough to flip the usual answer.

I made this call for real. My Digital Sevak's white-label client portal is a PWA, and I'd make the same call again — but not for the reasons most PWA advocates give, and not without real costs I'll be honest about below.

What's the actual difference for a client portal?

Strip out the consumer-app arguments and the comparison narrows to six things that genuinely matter when the users are your clients:

The row that decides it is the first one. A client portal's entire value depends on the client actually opening it — and every step between "I got a WhatsApp message" and "I'm looking at the post" loses people. "Tap this link" survives that journey. "Go to the App Store, search for our agency, download, then log in" does not, especially with the brand-owner who is 52, runs a jewellery business, and has 300 unread notifications.

The second row decides how you'll feel about it in year two. A client flags a bug in the approval flow at 4 PM. On a PWA, that's fixed and live before dinner. On native, it's a rebuild, a submission, and a review queue — Apple says on average 90% of submissions are reviewed in under 24 hours, which is genuinely good, but it's still a day, and it's still followed by waiting for clients to actually update the app they downloaded once.

Does push actually work on iPhone now?

This is the question that used to end the argument, and it's the one most India-facing blog posts still answer with three-year-old information. Yes, it works — with a catch worth understanding precisely.

Apple's WebKit team shipped Web Push for Home Screen web apps in iOS and iPadOS 16.4. Three conditions apply: the site must be added to the Home Screen, it must serve a web app manifest with display set to standalone or fullscreen, and the permission request must follow a direct user interaction such as tapping a subscribe button. The same release added the Badging API, so the app icon can carry an unread count — which for a portal means the client sees "3" on the icon when three posts are waiting for approval.

So on iPhone, push isn't gated on the App Store. It's gated on the client adding your portal to their home screen. That's the real cost, and here's the sharper version of it: Safari has no install prompt. Chrome on Android fires beforeinstallprompt and you can show a one-tap "Install" button. iOS has no equivalent — the user must open the Share sheet, scroll, and find "Add to Home Screen." Google's own PWA documentation is blunt about this: you have to detect iOS and teach the gesture yourself.

What does going native actually cost an agency?

Not the development quote — the ongoing tax. Store fees are the smallest part: the Apple Developer Program is $99 a year and Google Play registration is a one-time $25, so about $124 in year one. Trivial next to what surrounds it.

The part that catches small agencies is Google's testing gate. If you register a personal Play Console account after 13 November 2023, Google requires you to run a closed test with at least 12 testers opted in continuously for 14 days before you can even apply for production access. Twelve real people, on real devices, continuously enrolled for two weeks — and if someone opts out mid-way, the clock restarts. For a five-person agency in Nashik trying to ship a portal to eight clients, that's a two-week bureaucratic detour before a single client sees anything.

Then there's the permanent overhead nobody quotes:

• You still build the web version. Clients will open links on desktop. So native means two extra codebases, not two total.
• Version fragmentation. Some clients are on the build from March. Your support conversations now start with "which version are you on?"
• Every white-label client is a new listing. If you sell branded portals to clients, native means a bundle ID, a store listing, screenshots and a review per brand. This is where the native route stops being expensive and starts being unworkable.
• Store policy risk. Your portal's availability now depends on someone else's review decision.

When is native genuinely the right call?

I'm not going to pretend PWAs win everything. Build native when:

1. You need capabilities the web can't reach. Background location tracking, deep OS integration, on-device video editing, biometric-bound local storage. A portal for reviewing and approving posts needs none of these.
2. App-store discovery is your acquisition channel. If strangers should find you by browsing, you need a listing. A client portal is the opposite — nobody discovers it, they're invited to it.
3. Your buyer demands it. Enterprise and government procurement sometimes has an "is it in the app store" checkbox. That's not a technical reason, but it's a real one, and it's the only case where I'd override everything above.

What I'd reject as a reason: "native feels more premium." In 2026, a well-built PWA on a home screen — own icon, no browser chrome, splash screen, push, offline shell — is indistinguishable from a native app to a non-technical client. Ours is, and in three years no client has ever asked whether it was "a real app." They ask whether the notification arrived.

How to make a PWA portal clients actually install

The technology is the easy half. The adoption is where portals die. What worked for us:

• Install it for them on the kickoff call. Screen-share, walk them through Add to Home Screen, watch them tap it. One minute during onboarding beats six months of nudges.
• Ask for push permission at a moment they want it — right after their first approval, not on first load. Denied permission on iOS is expensive to recover.
• Make the icon theirs, not yours. Your client's brand on their home screen, delivered by the manifest. This is the single biggest advantage over native, where every brand costs a store listing.
• Have a fallback for every notification. Push is best-effort on every platform. Email or WhatsApp as backup for anything that has a deadline.
• Keep the first screen answerable in five seconds. "What needs my approval?" — that's the entire job. Everything else is a tab.

That's the portal we ship inside My Digital Sevak: a mobile-first PWA where each brand gets their own branded install, approvals arrive as push, and the whole thing updates the moment we deploy. If you're weighing this build for your own agency in a market like Pune or Surat, the honest arithmetic is that the months you'd spend on two native codebases buy you nothing your clients will notice — and cost you the one thing they will: the fix that ships today.

Frequently asked questions