zlacker

> if your app's entire functionality could be done in a regular website or PWA, then you can't put a native app on our stores

A very silly threshold, since this would knock out probably 95% of the app store, including games, since "websites" are extremely capable these days, with full 3d graphics, etc. Then, each time safari added a new modern browser feature, more would get knocked out.

>>nomel+(OP)
Why is that a bad thing? Wouldn't we be better off with all of them being PWA's?

>>joseph+y
It's not a bad thing for users. It would reduce the ability of Apple and Google to extract revenue from their stores though, so they're motivated to do the opposite.

>>nomel+(OP)
I think that's a little overstated. Part of a game's functionality is performance and native controls. A website can technically do those things, but the JS and WGL requirements will significantly hamper performance, and getting a browser to hand over native, first-class control of the device to the website is largely impossible and usually ends up an awkward mess.

And that little asterisk would end up getting abused by pretty much everyone. After all, we wouldn't be able to add the same functionality to the website because the developers we employ for this are only proficient in `<native language here>`.

By-intent, it would definitely be a big chunk of the apps out there, but I would argue that's a good thing. I don't want an App for every brand I interact with, especially since I know what they're doing (harvesting my data to sell to brokers to make a fraction of a penny more per transaction).

>>joseph+y
Gotta love the HN bubble. Users want apps, not PWAs.

>>karanb+52
If Apple wanted to make PWAs look like apps, users wouldn't be able to tell the difference. Except that's not what Apple wants at all.

>>frollo+A4
If apps were interchangeable with PWAs we'd just call PWAs apps. What would be the difference, besides distribution?

>>dpkirc+j5
That would be good too, "progressive web app" is a silly name

>>Zak+W
For more complex apps, efficiency could be a considerable issue. As capable as the web has become, it’s not very battery friendly for more advanced use cases.

>>frollo+A4
I don’t think that’d be possible without a considerably different web engine than currently exists. Even on desktop with Chrome which is the best case scenario currently, web apps are visibly different from their native counterparts due to differences in things like click handling, latency, etc.

>>cosmic+ia
Most apps nowadays are already websites inside a thin wrapper, and that part is just so it can go on the App Store and have certain OS integrations, not for the UI. Like yeah React Native implements a button with UIButton, but Safari also implements a button with native code.

Good example is Discord. Complex app, only really difference for native is something about push-to-talk.

>>frollo+Oa
Not quite, at least on iOS. React Native is the dominant non-native framework there. I run into web shells on occasion but they’re unusual relative to desktop.

>>cosmic+cb
Oh, I meant React Native, not an actual full-page UIWebView rendering the entire app (though there is that too). Yeah RN is a totally different renderer, but if something works in RN then I expect the same to work in web. Discord did both.

>>cosmic+9a
Sure, native apps can be good for users in some cases, but this post isn't about those.

>>karanb+52
I don't think the average non-technical person would know one from the other aside from the installation process. This situation didn't come about because users demanded native apps, but because companies profit more from them.

>>frollo+3c
RN isn’t quite a web shell, it’s more of a hybrid, though I have seen RN apps use webviews to inject web app bits here and there.

>>Zak+W
How many apps that could be websites have in app purchases of digital goods?