Comment by BiteCode_dev
8 hours ago
Apple makes sure it's not practical.
You still can't have a "share to" target that is a web app on iOS. And the data your can store in local storage on safari is a joke.
Of course, forget about background tasks and integrated notifications.
In fact, even on Android you miss features with web apps, like widgets for quick actions, mapping actions to buttons and so on.
And no matter how good you cache things, the mobile browser will unload the app, and you will always get this friction when you load the web app on the new render you don't have on regular apps.
Service workers solve the cache issue; web apps can run permanently offline after initial load. You may be a bit out of date on the state of the web.
No, I use them but loading and unloading the app in the tab still happens when the browser flushes the app from memory because the OS killed it or the browser eviction policy hits.
This loading is not nearly as seamless as a regular app starting back up.
For a regular app, you have the app loading, and the os cache helping with it. If you do your job half correctly, it loads as a block almost instantly.
For a web app you have the web browser loading, the the display of the white viewport in a flash, then the app loading in the browser (with zero os cache to help with so it's slower). It needs then to render. Then restoring the scroll (which is a mess with a browser) and the state as much as you can but you are limited with persistence size so most content must be reloaded which means the layout is moving around. Not to mention JS in a browser is not nearly as performant as a regular app, so as your app grows, it gets worse.