Live data from Hacker News

Private client-side-only PWAs are hard, but now Apple made them impossible

andregarzia.com

551–560 of 927 posts

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#551
post #500

Earlier quoted context omitted.

Well it needs to be downloaded from the internet at least the first time, so it's intrinsically going to be less secure than an app that you can guarantee never connects to the internet.

Your app needs to be downloaded the first time too. In fact, a downloaded app can run riot on your filesystem. A web app runs in the "cage" of the browser, and is arguably more secure and explicit about permissions it requests.

"... can run riot on your filesystem"? Citation needed because an app is as heavily sandboxed as a web page running in a browser. An ios app gets no view into anything you as a user don't choose to give it (no access to photos, etc).

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#552

Earlier quoted context omitted.

Then why not make it free?

That's easy. It adds a hurdle for people who make malicious or fraudulent apps. It's not free, but neither is it MSDN levels of absurdity.

I'd counter that: make it a one time tax, like the Play Store. Is it reasonable that I need a Dun and Bradstreet number to write an application for my computer?

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#553
post #549

Related discussion from earlier today: https://news.ycombinator.com/item?id=22683535 WebKit blog post from yesterday: https://news.ycombinator.com/item?id=22677605

I think we'll merge today's threads. Any reason not to? Edit: merged.

I can't think of any, they're all the same topic as far as I can see. The WebKit blog post has a little bit about third-party cookies being blocked but everyone quickly moved discussion to the script-writable storage cap.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#554
post #494
post #484

Earlier quoted context omitted.

No, it's a grab for money. Releasing an iOS app requires Apple hardware, X-code, and an Apple developer license which is $100/yr. Where as developing a PWA can be done on any hardware, and would be natively cross-platform. An offline PWA does not require an active connection, and in fact is the one of the reasons behind the idea of developing a PWA instead of a general webapp or website. All other browsers allow the…

I promise you that Apple does not give a shit about the revenue from the developer program.

Does Apple also not care about the huge cut it takes for everything sold via the App Store?

As lliamander said, if they don't care, why not make it free? I don't for a moment believe the argument about creating a barrier for negative actors. They could still screen apps before allowing them into the App Store, and if that mechanism is working reliably then the charge is unnecessary as a deterrent, while if it is not then the financial deterrent isn't going to be enough to stop a lot of people willing to make these kinds of apps anyway.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#555
post #483

The source clarifies that this only applies to websites run within the Safari browser.[1] PWAs added to the home screen aren't affected. > As mentioned, the seven-day cap on script-writable storage is gated on "after seven days of Safari use without user interaction on the site." That is the case in Safari. Web applications added to the home screen are not part of Safari and thus have their own counter of days of use…

If there is, as they say, a dedicated counter on those home screen applications, what is the threshold? Will home page PWA apps not used often (say, for infrequent uses like travel) have first party data deleted after the icon isn’t clicked for some time? This is highly unclear and confusing.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#556
post #539

Earlier quoted context omitted.

Okay?

I basically assume my phone is nearly useless without connectivity. And if I want something to work in that sort of environment, it better be a native app.

Okay?

...I guess I don't really see why the current state of things should block any future development. Browsers shouldn't ever implement new features because users today aren't expecting them to exist?

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#557
post #505

Earlier quoted context omitted.

It's not just about the revenues of $100/year. It's also the revenue from 30% sharing of profits. And most importantly, it's the bigger revenue generated from having apps that work only on iOS, which drives users to buy iPhones and iPads.

A PWA app isn't going to generate any 30% revenue share for Apple since no one is paying for it in the PWA case and thus likely won't be paying for it in the pure app case either.

Why would no-one be paying for a PWA? There are countless paid-for services available via web apps.

Providing even a free native app via the App Store to access a service with a subscription model becomes a very risky proposition given Apple's rules, though.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#558

That is terrible if you are working on a pwa game to cache assets offline. There should be some opt-in approach similar to location tracking in the background like some apps do. That seems way worse than simply having local data be relied upon. Not cool.

What's the problem with the client having to re-download those assets if they don't play for a week? Seems long enough that I'd expect a patch download on a typical gaming platform, for example.

Offline iPad kiosks

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#559
post #501

Earlier quoted context omitted.

"Web applications added to the home screen are not part of Safari and thus have their own counter of days of use."[1] From WebKit: [1] https://webkit.org/blog/10218/full-third-party-cookie-blocki... A Note On Web Applications Added to the Home Screen As mentioned, the seven-day cap on script-writable storage is gated on after seven days of Safari use without user interaction on the site.” That is the case in Safari.…

> Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. This is a baffling word salad. So they are tracking days of use of home screen web apps... which sounds like it means that if you do not use the app for seven days the cache will be deleted... but they don't expect a w…

The only coherent interpretation I can think of is that accessing example.com in a home screen app doesn't reset the timer for example.com in Safari. And vice versa. But it's still really unclear whether that implies that home screen apps get their data wiped or not.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#560
post #383

Workaround: encode your app's state into window.location.hash

That works as long as the user keeps the tab open, but if they use a bookmark (or just remember the domain), the hash part will be lost.

The hash part is not lost to bookmarks, unless Apple broke that too. If it was, no one's MEGA bookmarks would work.
Post reply on HN