If a native app can remain authenticated with whatever service it communicates with a PWA should be able to as well, that's an implementation issue rather than a PWA issue, no? Similarly if LastPass doesn't integrate correctly to the point where you're having to manually look up details rather than having details auto-filled across websites and apps (iOS and Android both support this), that sounds like an issue with LastPass.

With all that said, it's hard to deny that it's easier to keep a mobile app performant and flexible than it is a PWA. I'd also add to your list that native apps have familiar UIs by default, which is tricky to replicate in a PWA.

Native apps don't usually remain authenticated, but they'll allow you to store your credentials on the device keychain or secure enclave and it can be accessed with FaceID/TouchID making re-authentication completely automatic.

"Similarly if LastPass doesn't integrate correctly to the point where you're having to manually look up details rather than having details auto-filled across websites and apps (iOS and Android both support this), that sounds like an issue with LastPass."

We can surely blame the services, apps, browsers for not doing things correctly, but as an user I just want things to be fast, efficient and simple. Right now only native apps provide that experience.

"(iOS and Android both support this)"

Can you tell me how? I use Firefox, Chrome and Brave on iOS and have never seen any kind of Lastpass integration on them.

Thanks for the correction, I admit I have limited knowledge of production ready native app development! As with the UI issue, a PWA developer could still use the JS crypto APIs to roll their own secure store for credentials, or store something similar to an API key issued on successful authentication? Handling this kind of data correctly has a lot of pitfalls, which is likely why most PWAs still use standard authentication processes.

There are APIs and specs [0] [1] [2] that have been floating about for at least the last couple of years which aim to solve credential and authentication management in a more formal way in the browser, but as with many of these features, they're slower moving than the native SDKs. I still don't believe that makes it impossible to achieve a similar flow in a PWA but I certainly concede it's much harder to get right (secure and convenient).

"Can you tell me how?"

As a disclaimer, I jumped ship to 1Password before I jumped ship to iOS, so I've never actually done this with LastPass. But this article[3] appears to offer a similar experience to what I have with 1Password:

- I go to an app or website

- A prompt above the keyboard offers to autofill with credentials

- I tap it and authenticate with 1Password (it normally pre-filters the list by app or website I'm using)

- When I make a selection it autofills everything it can

In 1Password, there is also the option to keep your OTP seed stored too, in which case it will copy the OTP to your clipboard for a short time (and slightly invalidate the purpose of 2FA...).

[0] https://news.ycombinator.com/item?id=16801858

[1] https://github.com/WebKit/explainers/tree/master/IsLoggedIn

[2] https://w3c.github.io/webappsec-credential-management/

[3] https://blog.lastpass.com/2018/09/get-in-app-autofill-with-l...

- High battery consumption and no way to control background services

- 100% access to local user data

- Fast and unsafe languages such as C and C++ (yes they also come in the SDK tooling)

Web apps:

- Fast with WebGL 2.0, and proper use of hardware accelerated CSS

- Limited access is actually a positive

- WebAssembly

- Doesn't apply to iOS apps and background services are controllable and automatically shutdown unless there is specific purpose such as streaming music. Apps abusing these rules will be rejected and removed from app store.

"- 100% access to local user data"

- Completely false. No access whatsoever unless explicitly granted by the user.

"Fast and unsafe languages such as C and C++ (yes they also come in the SDK tooling)"

True, but marginally used and personally I'll take fast and unsafe rather than slow and unsafe.

"Fast with WebGL 2.0, and proper use of hardware accelerated CSS"

"WebAssembly"

- Valid points. These really are positive developments in terms of web dev. AFAIK WebGL would only give benefits in games and then you would be limited by connection and the process resources of the browser app. WebAssembly is cool, yet 99.999% of cases are basic React apps that don't get any benefits from either of these.

"Limited access is actually a positive"

- Not being able to make the app that you want to make as an web app can be seen as positive I suppose. In native apps there is not direct access to almost anything, but once permissions are given, apps can fully utilize the OS/Hardware features.

In English, unless you are developing apps for poor developing countries, you have to consider iOS users and often the iOS is the lead platform.

Couple of years ago I was developing app for well known Fortune 500 consumer brand in China and while iOS market share was about 15%, amount of iOS users for our apps were about 33% (1/3). When it came to customers actually using money iOS marketshare was somewhere around 40-50%.

Are you drunk? Native apps are orders of magnitude more efficient than browser rendered pages.

Also, wtf are you talking about, on Android your application will be literally killed if you don't post a foreground notification and do something in background without user's notice.

> - 100% access to local user data

Hello SAF and scoped storage, the future is here.

> - Fast and unsafe languages such as C and C++ (yes they also come in the SDK tooling)

?

Thanks for registering yourself to make such constructive remarks.

A local app doesn’t have access to a data outside of its own sandbox unless the user explicitly gives it to them and then it’s still limited.

But as far as “availability”, how many people have high end Android phones with decent GPUs for “with WebGL 2.0, and proper use of hardware accelerated CSS”? Most Android phones sold are low end with crappy hardware.

I target devices that customers actually have, not what they might have on local store windows.

Ironically, iPhones do better on web benchmarks than almost any Android phone.

Web apps:

- Fast with WebGL 2.0, and proper use of hardware accelerated CSS

- Limited access is actually a positive

- WebAssembly

None of that is going run well on the average low end Android phone.