Earlier quoted context omitted.
> I still, will never understand the need for native "Apps". To this day, I have never seen an "App" that couldn't simply have been a website/webapp. In cases where a native app and web app are both available on iOS, there’s often a huge difference in battery usage and sluggishness. Also, as a sibling poster mentioned, I like having fully “offline” apps as well, for example for maps and notes. I’m not saying that I l…
PWAs can be fully offline. Are you sure you understand what you criticize?
Here are some of the frustrations I had with PWA's.
There are massive differences between browsers and Android/iOS when it comes to storage, access to local files, and size limitations. Proper backup/sync of large files using IndexedDB, Cache API, or localStorage is not as straightforward as native storage.
Service workers aren’t designed for complex or long-running computations, But they’re more like lightweight assistants, and you would have a HUGE pain trying to accommodate all the different browser/OS limitations if you need predictable background sync/backup. This seems maybe to be better going forward due to frameworks like Ionic/Capacitor or Workbox.js tho.
PWAs are tethered to the web’s security model, which means they’re generally restricted to HTTP and HTTPS for communication. This limits direct access to protocols like SMTP (email) and FTP (file transfer). You’re stuck with web-friendly options like WebSockets or WebRTC, or you’ll need a server to act as a middleman. Building a torrent client would be really annoying due to the limited protocol access. The WebTorrent JavaScript framework, which can run in the browser, does not fully support traditional TCP/UDP torrent protocols directly but instead relies on WebRTC data channels. Therefore, your app will only connect to peers supporting WebRTC, which significantly reduces available torrents and peer counts. Also, there often is an added level of restriction to background processes on mobile.
There are also limits to access of the devices APIs: - NFC (partial Web NFC support in Android Chrome) - Bluetooth (Web Bluetooth limited to Chrome Android, absent in iOS) - Native contacts, SMS inbox, telephony, or system-wide calendars. - Some system-level sensors (barometer, precise accelerometer data).
Also: Web apps often perform slower on heavy graphics or computation than native apps due to lack of direct GPU access. I have not tested this myself, but I know this has gotten better.
Onwards: - PWAs can't directly register as the default handler for specific file types or URL schemes across the OS. - PWAs cannot reliably run background tasks (like precise location tracking, audio playback, VoIP callbacks, or continuous data monitoring) when inactive. - WebAuthn supports biometrics, but native biometric APIs (like Face ID/Touch ID) offer deeper integration for specific app functionality. This is a HUGE need for our firm, as we rely on it for easy authentication for our app, and customers love it over other authentication methods. - PWAs can't easily embed widgets into the OS home screen or system-level UI components like control center integration.
YES, PWAs are much more capable than some people think and could, in many instances, work just as well as a native app. (I use GeForce Now on iOS with not many problems.)
And this is not even touching on how much easier it is to use Android/iOS SDKs to put together an application, and user expectations (which might be WRONG when they think PWAs are lesser or more insecure, but these attitudes are still reality).
All that said, I prefer PWA over native myself due to publication freedom, but I get annoyed when you talk down to people, and you seem to be the one that doesn't understand that there are actual limitations.