PWA vs native app — when does the browser win?

Verdict

Short, bounded tasks (file processing, calculators, viewers, dev utilities) → PWA is enough, and often better. Install via URL, update silently, no app-store gate.

Long-running background work, deep OS integration, hardware, heavy memory, or app-store distribution requirement → native app. The browser can’t reach these.

Most “is it really an app?” tools — note-takers, calendars, calculators, tool sites like Loft — sit firmly in the PWA-is-enough category. The user experience is roughly indistinguishable from a native app for the user.

Side-by-side capability table

Capability	PWA	Native app
Installable to home screen	yes	yes
Runs offline	yes (service worker)	yes
Updates automatically	yes (silent on reload)	usually requires user action / app store
Cross-platform from one codebase	yes	usually no (one platform per build)
Available outside app store	yes	usually no
Memory headroom	bounded by tab (per-tab memory cap — typically low hundreds of MB on modern iPhones)	bounded by device RAM
Background processing after close	no	yes
Push notifications on iOS	limited	yes
Deep OS integration (widgets, shortcuts)	no	yes
Hardware access (USB, scanners, low-latency audio)	partial	yes
App-store presence	no	yes
Discoverability	search engines	app store search
Update lag	seconds (page reload)	hours to days (review queue)
File-system integration	partial (File System Access API where supported)	full

When PWA is the right call

• Short, bounded workflows. Open → do task → close. The “no background processing” gap doesn’t bite.
• Cross-platform parity matters. A single PWA covers Windows, Mac, Linux, ChromeOS, Android, iOS from one codebase.
• Updates need to ship fast. PWA updates land in seconds. App store reviews can take days.
• The audience isn’t app-store-driven. Users find you via search and direct URL, not app-store browse.
• The app’s value doesn’t depend on platform-native integration. If you don’t need Touch Bar, Shortcuts, widgets, or system-wide search, PWA is fine.

When native is the right call

• Background processing matters. Backup tools, sync clients, alarm clocks, anti-virus, anything that operates while you’re not looking. PWAs cannot.
• Tight OS integration is a feature. Shortcuts.app on Mac, System Settings panes, widgets on iOS, share-sheet extensions — all native-only.
• The app needs more memory than a browser tab. Professional video editing, big CAD models, scientific computing on real datasets.
• Real-time hardware control. USB scanners, MIDI controllers, printer drivers, low-latency audio interfaces.
• App-store distribution is the business. If your customers find you in the app store and pay through it, PWA isn’t a path.

Which should I pick when

I’m building a PDF tool / image tool / calculator / converter — PWA. Short bounded tasks. Loft is in this bucket.

I’m building a fitness tracker that runs in the background — native. PWA can’t keep recording when you switch apps.

I’m building a note-taking app — either, depending on whether sync and rich notifications are core. Notion’s PWA is good enough for most users; Apple Notes’ native integration is worth the platform lock-in for users who want it.

I’m building a video editor — native. The memory budget alone rules out PWA.

I’m building a developer utility (linter, formatter, validator) — PWA. Run once, copy result, leave.

I’m building something that needs to be in the App Store for distribution reasons (school IT requires it, employer-managed device) — native. The PWA install path doesn’t satisfy the IT policy even if it’s technically capable.

Loft’s choice and its costs

Loft is PWA, not native. The reasoning:

• Our workloads are short, bounded, file-based.
• One codebase, not three (web + iOS + Android).
• Updates ship in minutes, not days.
• We avoid app-store gatekeeping and platform fees.
• Browser-side architecture is the moat; native would only add surface, not capability.

The honest tradeoffs we accept:

• iOS PWA install discoverability is poor. Most users never realise they can install a website. We do what we can with an install prompt; the gap is on browser vendors, not us.
• iOS Safari evicts caches aggressively. A PWA you haven’t opened in a while may need to re-fetch its shell.
• Heavy workloads hit the tab memory cap. A 500-page scanned PDF can struggle on iPhone where Acrobat wouldn’t.

For occasional file work — what Loft actually gets used for — the tradeoff is fine. For a user who runs into the limit every day, a native app from a different vendor may genuinely be the better fit.

A subtlety I keep getting wrong

I sometimes describe PWAs as “just a website with an icon.” That’s not wrong, but it undersells the service-worker piece. A normal website without a service worker isn’t installable, doesn’t work offline, and doesn’t behave like an app. The service-worker layer is what does the heavy lifting. The icon is the user-visible part; the worker is the engine. Worth correcting the next time I write this kind of post.

---

The pillar at /docs/how-it-works/ covers PWA install in section 8. The MDN PWA overview is the canonical reference.