Live data from Hacker News

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

andregarzia.com

891–900 of 927 posts

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

#891

Earlier quoted context omitted.

If you read the article, that's the issue the author was talking about: it's basically impossible to make an app that can store its data locally, instead of on some web server. All apps that you download from App Store can live offline, where they're usable without Internet or trusting some faraway web server. You can't make a web app that can do that, and to some people it smells like Apple trying to force developer…

Who are the “some people”? Are any of them outside of chrome’s WebWorker team, or the community of devs that were suckered into a model that really has never gained traction for iOS? I’m sort of sympathetic to the devs who bought in to the solution, but this looks an awful lot like a pr pressure campaign that is unhappy with how this affects googles disintermediation goals.

It didn't gain traction because iOS killed it. Also "some people" includes everyone who doesn't want to make an iOS app.

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

#892
post #182
post #148

Earlier quoted context omitted.

With cookies you can set the expire time yourself, as a developer. And looking at the list of the original blogpost from webkit ( https://webkit.org/blog/10218/full-third-party-cookie-blocki... ) it shows the following will be affected by the 7 day cap: Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations Since cookies are not mentioned, I'm assuming it's NOT affected by the 7 day cap bu…

If the cookie is set by http headers, yes. If it's set with client side js, though, it's capped at 7 days (since ITP 2.1).

Secure + HttpOnly do not expire at 7 days. These are invisible client-side.

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

#893

Earlier quoted context omitted.

The moment you offer in-app payment, apple gets a cut. This goes as far as not allowing apps that link to payment outside of the appstore's payment system. There is a huge number of cordova apps out there. These are webapps inside a native wrapper, to access exactly those features that are crippled in safari. Reliable storage, push notifications, and not much more.

Yet dozens on companies have had successful businesses not doing in app purchases - like Amazon.

Yeah big players get an exception - not a good example.

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

#894
post #710

I ported Polar ( https://getpolarized.io/ ) over to a PWA about a year ago. It's kind of a nightmare due to both Google and Apple messing things up. PWAs could be an amazing platform but both companies are really messing it up. Apple is trying to kill them by giving plausible explanations as to why they can't have PWAs. Security this, blah blah blah. There's no reason they can't have PWAs work well in Safari other th…

I tried using your app on an iPhone (with Add to Home Screen). - If I press the settings gear, the text on the settings page is about twice as wide as the screen, requiring horizontal scrolling. - On the front page, if I open the color picker, it's partially offscreen. - On all pages, if I do a scroll gesture in the wrong direction, it scrolls the entire UI rather than just the scrollable part. Admittedly, iOS has lo…

Are you sure that's not a catch-22? The reason you've not seen any good PWAs is because the ecosystem doesn't exist for making good PWAs, which doesn't exist because there aren't any good PWAs. Any sane technologist is going to look at the shortcomings of PWAs, and choose a different technology to build their app. Choose boring technology[0], and unless your product is a PWA toolkit, the app UI library isn't the place to get creative.

The single issue with PWAs, on iOS, is how do I add a PWA app to the home screen? I go to the app store and search... and your app isn't there. As developers we innately understand why that's so, but our users don't and shouldn't need to understand the difference.

[0] https://mcfunley.com/choose-boring-technology

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

#895
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…

Good luck getting your app added to the home screen. It only works through safari, so chrome or firefox users are ruled out, and it's hidden under some "bookmark" or "share" menu that is too difficult to discover.

Safari is the only browser on iOS because Firefox and Chrome are forced to use the Safari engine due to "security reasons".

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

#896

Earlier quoted context omitted.

Good luck getting your app added to the home screen. It only works through safari, so chrome or firefox users are ruled out, and it's hidden under some "bookmark" or "share" menu that is too difficult to discover.

Safari is the only browser on iOS because Firefox and Chrome are forced to use the Safari engine due to "security reasons".

The issue is that if you're using the Firefox or Chrome apps (which are the same rendering engine underneath), they aren't allowed to implement the "add to home screen" action in their UI.

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

#897

Earlier quoted context omitted.

A clearer explanation has now been delivered by Safari’s evangelist: https://twitter.com/jonathandavis/status/1243228885006708737 Data isn’t deleted after 7 days for home screen web apps.

Jesus christ. It sounds like there's a time bomb in safari web views just waiting to happen. The timer is supposed to be reset every time you open the app, so there won't ever be seven days of opening the app and not using it. But it sounds like the code path is just there, they just don't ever expect it to be hit because the timer _should_ reset every time the user opens the app. I can't _wait_ to deploy an applicat…

I actually suspect the reason the codepath is still enabled is probably to do with third parties running in a PWA context. That said I don’t see how this is actually all that flimsy of a mechanism, it avoids needing a special case. As it is you can’t really count on browser local storage alone for long-term storage; the same is actually true for Android and iOS apps too, who lose all of their local data when they are deleted. (It is possible for at least Android apps to write data to other places like the SD card, but that is a totally different story imo.)

Honestly, if my data really matters, I don’t want it to be stored only in a single place. I can get the argument of wanting to have federated syncing, that would give the user freedom to choose where data syncs or doesn’t. But in my opinion you either care about the data or you don’t. Any data stored locally anywhere should be considered lost until proven otherwise. Like, drop your phone in a sewer, leave it in the wash accidentally, have it stolen, or even just have a different software bug obliterate your data and it’s gone. That’s the definition of fragility.

This mechanism failing is mostly theoretical, but having ones phone break is not; I would guess those of us who have been using smartphones for 10+ years have, by and large, all experienced data loss when storing data with no backup.

To relate to your statement, can you imagine if your data on Dropbox was stored on one harddrive, in one server, in one datacenter? Servers fail constantly. You can of course do whatever you want to improve reliability but without redundancy you are very much pissing in the wind.

On the note of “localStorage is temporary,” nothing in the spec defines how long localStorage persists, just that it is not bound to the session. In fact though, Safari already deletes localStorage when disk space is running low.

I am very much an advocate for folks being able to control their own data. I personally self host a lot and use a Synology NAS as my own backup for most things. But I think Safari would be wasting time to disable the counter entirely for PWAs. It doesn’t meaningfully change the likelihood that users will lose data. I think users often do want strong durability and privacy, and an API that n apps from needing to implement many remotes would be way more impactful. I’d love to tell an arbitrary notes app, “Go backup to this Synology NAS” without it needing to specifically support Synology NASes or for example, WebDAV. Put the provider on the clientside and you have a place to implement end-to-end encryption.

(Of course, Apple has iCloud backup, but I don’t think that covers your localStorage content anyways.)

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

#898

Earlier quoted context omitted.

By your logic they should just remove push notifications completely from iOS because it uses power. Wouldn't that be bad? Web push is better than native app push when it comes to power consumption as web push is stricter on what you can do.

If an app on the app store abuses push notifications though, they can get kicked. Apple can’t kick a website off the web.

Technically they could blacklist certain behaviors from certain sites. They and all other major browsers already do this in a privacy-preserving way for Safe Browsing, certificate revocation, etc.

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

#899
post #897

Earlier quoted context omitted.

Jesus christ. It sounds like there's a time bomb in safari web views just waiting to happen. The timer is supposed to be reset every time you open the app, so there won't ever be seven days of opening the app and not using it. But it sounds like the code path is just there, they just don't ever expect it to be hit because the timer _should_ reset every time the user opens the app. I can't _wait_ to deploy an applicat…

I actually suspect the reason the codepath is still enabled is probably to do with third parties running in a PWA context. That said I don’t see how this is actually all that flimsy of a mechanism, it avoids needing a special case. As it is you can’t really count on browser local storage alone for long-term storage; the same is actually true for Android and iOS apps too, who lose all of their local data when they are…

> Honestly, if my data really matters, I don’t want it to be stored only in a single place.

That's all well and good except when you lose your emails that your wrote on the plane and didn't get a chance to send yet.

I'm not arguing that you should _never_ synchronize the data off the phone, but where I store data on my phone should be as robust as possible. So far I have never had my phone delete an application I had installed, but my browser loses local storage, cache, cookies, all the time. It is just not a robust storage location, and this new safari behaviour makes me trust it even less.

As a result, the web is continuously behind native apps for offline or semi-offline operation. There's no reason for that other than the shoddy engineering going in to web browsers, such as this recent addition to safari.

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

#900
post #342

Earlier quoted context omitted.

why to store JWT in local storage. Localstorage can be accessed by CDN scripts also. Please don't put risk on ur users data.

Localstorage is limited to a domain, a common security model in the browser also used by cookies, and prevents cross-origin leaks... (unless a developer volunteers to expose the data via postmessage whose destination can also be limited to specific origins). This is also why it is important to load your apps JS on your domain or same-origin and not offloaded to a 3rd party server which you might not control (librarie…

It's sad there are people not aware that cross-origin policies are actually helping them. They are the most misunderstood, hated policies.
Post reply on HN