Maybe, maybe not. I’m usually somewhat reluctant to install apps just because (and will immediately uninstall an app that requires a facebook login to work (but the same for a website)). However, if it’s something that I expect to use, there are certain assumptions I can make about a native app.
For one thing, I know that you’ve probably tested it on something like my device, and the UI controls will be on screen. None of this locked viewport crap. I don’t know what mobile site developers use to test, but it seems like half the time the answer is definitely not an iphone. It takes some real effort to get a genuinely unusable iOS app in the store.
As a user, there’s a certain inertia to overcome before I install something, but I’m generally happier when I do.
500kb of is enough to build a site and polyfill every interesting modern feature + write a substantial single-page app - see e.g. my project of last year - https://askizzy.org.au - it has basically every inefficiency you could ask for (fonts, single-page-app bloat, polyfills, etc) and is still quite fast on a iphone 5 & up.
Edit: Argh, I don’t know who is working on it now; when I left the project a few months ago the whole page weighted ~150kb and half of that was the font.
I’m concerned about what “service workers” cost: it’s a piece of code that gets cached and run locally, and interacts with the backing web service in extremely sophisticated ways.
What’s the storage limit? How do you delete service workers you don’t want? What are the privacy implications? Are users expected to learn manage another genre of “app?”
“Native apps are doomed”…“Native Apps are Not Dead Yet”
Which is it?
That depends on the phase of the computer sciences cycle we’re in, I guess…
Both. They’re doomed in the long term, but not dead yet.