Comment by illuminati1911 | Hacker News Reader

Comment by illuminati1911 | Hacker News Reader

"Before users can use your app you need to get them to download it first. So you will need them to: - go to the App Store/Play Store - search for your app - click to install - accept permissions - wait for it to download In each of these steps you can lose 20% of your potential users."

True.

Then again, when users have installed the app they need to:

1) Open it by a single tap

<Automatic face id authentication>

2) Enjoy

With a web app:

1) Open Browser

2) Type in the URL or...

2) Open settings/options menu of the browser

3) Select favorites

4) Scroll through the list until you find your web site

5) Open the website

6) Realize you are not authenticated

7) Tap login

8) enter username

9) WTF was the password

10) Close the browser

11) Open lastpass etc

<Automatic face id authentication>

12) Search for the website and open it in lastpass

13) Copy password

14) Close lastpass

15) Open browser again

16) Paste password

17) Tap login

18) Enjoy...?

Not to even mention high performance 1:1 user experience vs laggy and slowly loading websites, safety of app store, privacy protection by "Sign in with Apple" etc.

From developers' perspective:

Mobile apps:

- High performance

- 100% access to local SDKs, features, hardware (not exactly 100%, but only limited by the OS)

- Elegant, fast and safe languages with static typing such Swift and Kotlin

Web apps:

- Slow

- Limited access or no access

- JS

Of course if you are developing software for media outlet etc. (app for reading news) then it's probably not worth the effort to build native app vs mobile first website.

I'm not wild for PWAs but your suggested web app flow sounds like failings in the authentication setup of the PWA and of LastPass rather than the failings of PWAs in general.

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.

"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?"

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.

"Native apps don't usually remain authenticated"

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...

Or just save it to your home screen ...?

Mobile apps:

- 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

iOS - you can disable background processes on a per app basis.

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.

A feature available to 13.4% of mobile phone population across the world.

The iPhone is available in almost all of the world. Whether they choose to buy one is a different story.

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.

More than those that can afford iDevices.

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

The average selling price of an Android phone is $250. How many of those have decent GPUs or perform well enough to run web apps as well as native apps?

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

Plenty, if one doesn't bomb them with SPAs to draw static text.

That may be true, but you specifically said....

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.

"High battery consumption and no way to control background services"

- 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.

85% of the world doesn't enjoy those iOS benefits, as per mobile OS market share.

Do you develop apps targeted at China, India, etc? Once you ignore developing countries, the market share of iOS grows a lot higher. If you target North America for instance, you’re close to 50%

Yeah, up to 28% in Europe, our main market.

Global market share is not relevant. Target group(s) of the industry the application will be developed for and market share of iOS users amongst them is.

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%.

> - High battery consumption and no way to control background services

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)

?

It is always a matter of how they are programmed. And no, I am not drunk.

Thanks for registering yourself to make such constructive remarks.

Reply on news.ycombinator.com