Live data from Hacker News

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

andregarzia.com

321–330 of 927 posts

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

#321

I’m guessing that Apple will start hindering web apps because the new mouse support in iPadOS is going to be such a boon to web apps. Because of sandboxing, web apps are the only cross-platform apps that can run in their full versions on iPadOS. I wrote a quick summary of the situation[0]. Therefore, since native apps are more of a platform differentiator than web apps, moving forward we can expect Apple to start sys…

moving forward we can expect Apple to start systemically hindering web apps They have been doing this for quite some time now. Always ostensibly to protect users but always also conveniently putting webapps at a permanent disadvantage to native apps. For my part I'm not interested in being a user of a platform so hostile to the web that it disallows any third party browsers.

Technically it's disallowing third-party JITs / executable data. Which is a good thing all-in-all.

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

#322

This "feature" also invalidates the use case for WebCrypto API, since a user's keys would be stored in IndexDB, which now means keys cannot be safely persisted.

Exactly this. Most "non-custodial" web wallets will die as a result of this change (some may even lose money/assets). Very unfortunate Apple!

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

#323

I’m guessing that Apple will start hindering web apps because the new mouse support in iPadOS is going to be such a boon to web apps. Because of sandboxing, web apps are the only cross-platform apps that can run in their full versions on iPadOS. I wrote a quick summary of the situation[0]. Therefore, since native apps are more of a platform differentiator than web apps, moving forward we can expect Apple to start sys…

moving forward we can expect Apple to start systemically hindering web apps They have been doing this for quite some time now. Always ostensibly to protect users but always also conveniently putting webapps at a permanent disadvantage to native apps. For my part I'm not interested in being a user of a platform so hostile to the web that it disallows any third party browsers.

> Always ostensibly to protect users but always also conveniently putting webapps at a permanent disadvantage to native apps.

This isn't always a bad thing though. For example, Safari has prohibited some obnoxious behavior that Chrome has allowed: Autoplaying videos, tab suspension, push notifications. These hog CPU and destroy battery life, worsening the user experience.

Remember, making everything a web app is Google's agenda because they benefit most from it.

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

#324
post #179

Earlier quoted context omitted.

Apple disallows third-party web rendering engines. Google Chrome on iOS uses own networking stack. It is still a significant restriction, but it is rather understandable. Without it it could be just Blink everywhere at this point.

So it's not about what's best for the user but what's best for Apple? I wouldn't call that "understandable". All this is doing is contributing to webkit monoculture.

Remember, making everything a web app is Google's agenda because they benefit most from it.

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

#325
post #306

Earlier quoted context omitted.

Exactly, and when they get caught, they get fines or prison. Sounds good to me, let's ship it.

Let me correct that for you: When they get caught thet get a small fine(somewhere close to 1% of their profit) or no fine at all.

Well, we're talking about a hypothetical law here, so we don't really know the amount... The low amounts for fines when it comes to big companies is a different problem that should also be fixed.

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

#326
post #129

Earlier quoted context omitted.

People who want to track users will always find a way to do so, it's a endless cat-and-mouse game. Now they will just use cookies instead... The only way to win this is to legislate away the freedom to track users by using privacy-invasive methods. That's the only way that will work long-term. But that'll make half of the internet industry disappear, along with it's shareholders, so it's unlikely to happen.

Arbitrary government rules are never the solution for issues.

Now I'm not a native English speaker, but seems "arbitrary" means "determined by chance, whim, or impulse, and not by necessity, reason, or principle". Introducing a law to protect peoples privacy would not be arbitrary, especially since most countries have a due process for introducing laws.

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

#327
post #314
post #309

Earlier quoted context omitted.

For your app, maybe. But most apps cannot be used offline at all, and instead they use localstorage as another place that can store tracking cookie. So as a user, I fully support this change, because there should not be a loophole like this.

There are many legit uses for localStorage. Storing JWTs, game state data, etc.

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

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

#328

Earlier quoted context omitted.

Users are using other than macOS/iOS devices too. Most of them are not willing to pay extra for native app that runs on only one of the platforms used.

Why would users have to pay extra? If right now you have a web app with paying users, that means you have an accounting system of paying users. You could publish a "native" app that simply serves that web app through a web view, using those same accounts.

The issue is elsewhere: you need to pay your developers to develop the second app. You would most probably need to bring in one more team, for each native platform.

Will you get new users from that? If yes, they will pay for that (in principle). If not, just some existing users would migrate? Then you just increased your cost without increasing your revenues. So you would need to gain enough new users to make it worthwhile.

* * *

In a nutshell, it is the same reason why Adobe won't port their apps to Linux. They already have all the users that need their software, and while it would be nice for some of their users to migrate, it won't bring anything to Adobe.

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

#329
post #7

I have an app which isn't offline, but I wanted to make use of IndexedDB and LocalStorage to make things faster for users. Now I wonder if it's worth the effort to even try. I think this pretty much kills the utility of all local storage initiatives. My app is an inventory control system used by businesses that build electronics ( https://partsbox.com/ ). Deleting client-side data after 7 days is ridiculous. You can'…

Your demo page is 3.23 MB. ~500KB is javascript, ~500KB is CSS and another ~400KB is web fonts. The parts database is 24 KB. That's certainly not the first place I would look for an optimization target, even for customers with very large parts databases.

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

#330
Is there anything to stop an application from touching the cache periodically (in the Unix sense of updating modification timestamps without changing values) on load?

If so, assuming the application is used more than once every 7 days, this seems like less of an issue.

Post reply on HN