Hacker News new | past | comments | ask | show | jobs | submit login
Private client-side-only PWAs are hard, but now Apple made them impossible (andregarzia.com)
963 points by soapdog 12 days ago | hide | past | web | favorite | 896 comments





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. Their days of use will match actual use of the web application which resets the timer. We do not expect the first-party in such a web application to have its website data deleted. If your web application does experience website data deletion, please let us know since we would consider it a serious bug. It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.

[1] https://webkit.org/blog/10218/full-third-party-cookie-blocki...


I don't think that's actually what it clarifies. Or at the very least it's very confusing.

> 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 makes it sound very much like homescreen apps will have their data wiped after 7 days of non-use.

> We do not expect the first-party in such a web application to have its website data deleted.

And this does not. It's a very confusing word salad.


Yes, it's confusing.

It's not 7 days of non-use, it's seven days of application use without visiting the site.

Safari is one application, the homescreen app is a separate application. Presumably, all the alt browsers or WebView apps are separate applications as well.

Since you can't use a homescreen app without visiting the site, the 7 days of not visiting the site can't happen.


What if you visit a link within the home screen app that takes you to another domain? Presumably if you kept using it with ever returning to the original domain the clock would be ticking.

will it be "7 days of non-use" for regular websites that use localStorage?

You can't really have "seven days of application use without visiting the site".


For "regular websites" (visited through Safari) it's 7 days where you use Safari, but don't visit the site. So if you go on vacation for a month and don't touch your computer, or if you switch completely to using Firefox for a month, localStorage will remain untouched.

Where is this explained?


Hmm no mention about "regular websites" there...

I fail to see why you need to see a mention of "regular websites". The comment clarifies the situation of what occurs if a user goes on vacation or switches to another browser: nothing will be deleted, as Safari is not being used.

Ah OK that makes sense. They should really copy and paste what you just said into their post!

So this is a requirement that all webapps phone home, moreover that they have a home to phone?

No, this is all internal to the browser, no requirement to send a remote request.

It’s a requirement that some time within the next seven days of app usage, the user interacts with the web app.

This might cause trouble if the web app is simply a list of timers which the user interacts with passively (map of earth showing day/night zones), but if there is any interaction at all the timer resets.


I'm not getting the semantics clear but wonder whether having the icon on the homescreen counts as "visiting" or whether suspending the app first day and reopening it the next day counts app-subjectively as "continuing day one" or "reopening immediately"

But .. if you don't use Safari for seven days, what happens?

From their description, nothing. Seven days of use without visiting triggers deletion. Failing to satisfy either of those conditions (either by disuse of Safari, or by visiting the site within seven days) doesn't.

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 application where there is literally an "rm -rf" pointed at my users data, with a complex conditional blocking it. That makes it far to easy for a webview bug to nuke my users data.

This is shoddy engineering. Could you imagine a filesystem being implemented the same way? You would never include a code path in your "mount" logic the says "if ( some condition ) delete everything;" that would rightfully be viewed as a terrible idea and a disaster just waiting to happen.


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


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


Web apps are unreliable for sure, but I think that is where PWAs should come in. The problem is there’s just not a ton of them today, and parity just isn’t there. That having been said, I’ve never lost local storage on a PWA in any OS so far...

Also I am not saying programs and browsers should not make a best effort to reliably persist data locally... just that robust local storage only really needs to be so robust, because any more robust and you might be fooled into relying on it.


I've lost localStorage on PWAs before. But that was a number of years ago when I was still bothering to develop them. I also lost data in appcache repeatedly, then service workers came along to fix that, because the browser vendors' strategy for broken implementations is to deprecate them with an even more complex standard that they will never finish. Then they can close your bugs against the old standard that they never finished implementing as WONTFIX and everyone gets a promotion for shipping.

Home screen web app data will be deleted onlY be deleted after 7 days of active use of that web app without any user interaction, which is nearly impossible. So the whole premise of the OP is false.

Suffice to say that the author of this blog post should have spent less time congratulating themselves and more time clearly explaining the impact of this change, to avoid scaring off developers and users.

Ok but OTOH Apple is not helping PWAs by hiding the "Add to home screen" in submenus and not having an official API to show a banner like Chrome has on Android.

Edit:

Also what about desktop?


Not having a way for web apps to communicate a call to action dramatically reduces engagement with this feature, no doubt. The only way I can see this from Apple's side is they see it as a feature for Safari users, not from the platform side for the web.

From Apple's standpoint, when you put yourself on the user's homescreen, that is a deep connection between that app and the user. Apple spends billions in each finding new ways to enhance and enrich that connection. IMO, their _belief_ is that building a native app to take advantage of all these rich and engaging ways is the best way to build deep connections with your (developer's) users.

Being an icon on the user's home screen is where deep connection begins, not ends. You might add a today widget, you might want to send notifications, you might want to add AR experiences. You might want a Tablet experience and allow hand off between these devices. Apple is invested in becoming a deep level of importance in a user's life. They want to share as large of surface area with 3rd party developers as they can. It would be irresponsible to promote an API that made developers have to start from scratch when they decide they want to go deeper.


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

But said timer... does nothing? Why does it exist?


Presumably because WebView is available to other applications besides Safari and pinned sites, and they want to offer the same privacy guarantees to users for WebViews in apps as for Safari. Adding an exception for pinned apps is unnecessary because it's impossible to meet the criteria for deletion.

I suppose it would still affect any sites you visit from within the PWA, for example through an iframe.

Also, it's simpler to have a timer that effectively does nothing than having extra logic to suppress it.


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.

That's a relief. We've built our business on our PWA, which also has an offline mode. It would be annoying if we had to adjust it for (yet another) Safari quirk.

Except that by "Safari quirk" you mean "the way that all common browsers are heading".

Safari is the first here. Firefox is certain to be right behind them. Google, probably not, but I bet Edge does the same thing before too long.


I hope not. Apple has had substandard support for modern web technologies in Safari for a long time, to the point where it is often referred to in the industry as the new IE. We've had enough of browsers breaking things that used to work in the name of false progress. Time for the grown-ups to take a careful look and see this for what it is.

You realize that custom, new, cutting-edge APIs (can you imagine the web without xhr?) was what made IE into the IE we talk about. Some they got right, some they got wrong, some were way too tied into IE’s parent’s ecosystem (sound familiar, AMP?). It’s once it stopped getting updated that it became a problem, as no one else had or planned to have some of its stuff, resulting in it being an oddball. Chrome fits the first half of that profile far more than any other browser these days, it’s just that WHATWG being a “living standard” has enabled it to “standardize” any new idea that comes along (other browsers do this too, but not nearly as much as Chrome).

The point is that slowness to adopt new standards wasn’t exactly what made IE into the the IE we all hated; it was going off on tangents without consulting anybody too often that left it out on an island with custom versions of so many things. Fortunately it doesn’t seem like Google is going to lose interest on Chrome anytime soon.


It's not only custom cutting-edge APIs, there's a lot of common stuff which is broken in Safari, that's also why it's referred as the new IE. I personally had issues with forms, clicks, svgs, selects... It's really broken in many ways.

Chrome is the new IE in the embrace-and-extend sense (the early IE that won the browser war).

Safari is the new IE in the stagnating, not supporting new functionality, not fixing long-standing bugs sense (that same early IE several years later).

Neither of these is a good thing or to be encouraged.

Please don't get me started on the oxymoron that is "living standards". I think that idea is responsible for a great deal of what has gone wrong with the web ecosystem in recent years.


Here’s my take on what it is: the most battery-efficient browser. I’ll take 30 more minutes on my laptop before some nebulous modern web standard.

Would you also take gradually losing access to other modern web standards apps rely on as time goes on until the only realistic option we have for building, deploying, and consuming apps are the walled gardens controlled by 2 corporations who have arbitrary rules on who can and can't participate, freely stifling innovation/competition as their interests dictate, and taking a more and more outrageous cut of all economic activity on the platform?

That's where this is going.

> "first they came for localStorage and I did nothing"


How does something like allowing data to be stored by a web app that isn't even being used for more than a week cause your laptop to lose 30 minutes of battery life?

It doesn't as the two have no connections whatsoever. The point was that Safari is the most battery efficient browser overall on MacOS, so they're willing to put up with sub-standard support for web standards if their battery lasts longer.

I'm sure it will be a great comfort of them to not be able to use their computer for useful things for a bit longer before they have to plug it in. :-)

As an end user, I love it. I regret that it's making some things harder for legitimate developers, but love that it's making it harder for the assholes who keep trying to ruin the web.

Google is planning on implementing part of this in 2022[1]. Not sure what they are going to do about the browser storage though.

[1] - https://www.theverge.com/2020/1/14/21064698/google-third-par...


That article mentions third party cookies. Nothing about nerfing localStorage.

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.

The deletion occurs if you use the app for seven days and don't visit the site. Pinned sites cannot meet those criteria and will not trigger deletion.

How about pinned sites that have not been accessed for > 7 days? I neither use the app nor visited the site for e.g. 2 weeks.. what will happen to e data for e pinned site? Apple is being vague here.

One of the criteria for deletion is accessing the app for 7 days. If you don't access the app for 7 days, it doesn't meet the criteria and won't trigger deletion. It's poorly worded, but it's not vague.

Thank you for the clarification.

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

What exactly does that mean? So you use the app for seven (perhaps non-consecutive) days, and now all third parties that haven't been, uh, interacted with, get their data wiped - but not the the first party, because that has been interacted with, by virtue of the PWA being launched in the first place?

I guess that solves the problem?


As the article has been updated to say, "installing" a PWA to the home screen is an optional step that many people prefer not to do in favor of bookmarks or the address bar or the new tab page or whatever.

But it's no surprise that Apple would want to impose an "install" step on the web to prevent it from looking more attractive than the App Store.


> But it's no surprise that Apple would want to impose an "install" step on the web

The FUD here is getting out of control. "PWAs", that Google pioneered, are all about having an ‘install step’ to put the "web apps" on your home screen. https://web.dev/customize-install/


No, they are about safely adding capabilities to the web that native apps have. Home screen icons are only one of those capabilities, and not the most important.

PWA is in fact a corporate born, bred and sponsored definition created to push and promote an _arbitrary_ set of Chrome features. It was an attempt to build momentum towards a vision for the web where browsers can run "open" apps. Unfortunately visions don't die, and thus the term lives on. Sigh.

It is no surprise because the whole point of keeping storage around is because you intend to come back. Pinning a website to a homescreen is clear intent. Having a tab or a bookmark does not make that clear. I have tabs and bookmarks open that I haven't visited in years. Thankfully Safari now kills tabs that haven't been touched within X time frame.

"impose" is the wrong word. I think you mean they are "trying to understand you and do the best thing"


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 than they want you to port your app to the App Store and get locked into their native APIs.

Google's problem is, well, they're Google. Meaning things are somewhat incoherent, docs are all over the place, they start new initiatives then abandon them half way, etc.

Consumers are another problem. They have no understanding of PWAs and they go to the app store, don't find us, and then complain we don't have an app..

The plan now is to use Google TWAs and port our PWA to Android.

We're going to do the same thing to Apple after we do the Android release BUT I think there's a 50% chance that apple will just flat out block us.

I think we might have a chance of getting around it if we use mobile gestures properly, use platform specific APIs like the camera, audio, and GPS that aren't on web and try to really integrate into the platform properly.

For example, they have an API to detect dark mode now. IF that's on we're just going to magically enable our dark mode in our app.


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 long made this hard to avoid without hacky JavaScript, but it's been doable, and it's much easier now [1].

- The hamburger button on the left opens a modal view that covers all of the screen but a small margin on the right, making it unreasonably hard to exit.

- If I try to create a tag or folder, the name prompt appears under the other modal view and is improperly sized.

- Oh, and the UI looks thoroughly non-native, e.g. Google-style floating action button, UI not covering the status bar, bottom tab buttons too short, etc. The animations are also haphazard.

My point is not just to nitpick. It's just that while I sympathize with the idea of PWAs in principle, almost every single time I see someone talk about theirs, the PWA in question has immediately obvious glaring UI defects that have nothing to do with browser limitations, and leave it far below the standard of a good native app, or even a bad one. I honestly don't know why this is, but experiencing it over and over makes it hard for me to care about PWAs.

[1] https://benfrain.com/preventing-body-scroll-for-modals-in-io...


There are some fantastic PWAs out there. Twitter is the one I use most regularly.

I think one of the reasons we see a lot of less-polished PWAs is that the idea of the PWA appeals to businesses at certain stages. Larger shops can afford to ship native binaries to more than one platform, but a smaller operation can't. PWAs are presumably tempting to those types of product teams: you get multi-platform reach while truly only writing for the web. The fact that their UIs have rough edges are probably a result of having an MVP-stage product.


Is Twitter really a PWA or just a nicely done responsive website? At this point the boundary is a unclear.

Beside Twitter rely on server side storage and pretty much only store session token in the PWA "local storage" (largely speaking).

And as a user I rather installed iOS native App to keep finer grained control on permissions. (I also use multi accounts not sure the PWA Handel that?)


This highlights a longstanding issue of PWA definition and how to position it against modern web practices and features. What is a PWA? Why is it even a thing?

It is absolutely a PWA, and an excellent one at that. You can add it to your home screen on the desktop and mobile platforms that support it; they have all the trappings of a native application including notifications support, background refresh, etc.

Twitter's "PWA" is crap. It has an unending stream of glaring UX/UI errors that only get worse over time.

I'm just gonna link to a small subset of failures we've documented: https://www.google.se/search?q=twitter+site:grumpy.website


Why enclose PWA in quotes? Just curious. I use Twitter's PWA weekly on more than one platform and it works great for me, but that's just one person's opinion. I prefer it over their native clients for a lot of reasons, but the main value-add is that I don't have to give Twitter access to detailed information about my system while still using a full-featured, first-party client.

> Why enclose PWA in quotes?

It's twitter's mobile site that they extended to cover both desktop and PWA. As a result, it's quite bad on all fronts and judging by the number of bugs that are lingering with no fixes, abandoned. At least they managed to almost fix the epileptic scroll position [1]

> I don't have to give Twitter access to detailed information about my system while still using a full-featured, first-party client.

Yes, this is, without a doubt, the best value-proposition of PWAs.

[1] https://grumpy.website/post/0RQvmdNmN


Writing for the web and trying to be consistent with native UI is a nightmare. It is not about MVP-stage or not, it is simply not worth it.

There's no rule that says that an app UI must be consistent with native app conventions.

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


Hi there, I'm the product manager for PWAs on the Chrome team.

Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t

Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recently (https://web.dev/progressive-web-apps). Consolidating and adding docs is an active area of investment, and our goal is to create a well lit path for developers to succeed with PWAs.


Well, it would have been helpful to provide a simple example of a working pwa.

The example at

https://codelabs.developers.google.com/codelabs/your-first-p...

was way too complicated as a first example, if all I wanted to know was how to make my app installable and is also broken as it uses some outdated tools. (don't remember the details)

Also, it could have been mentioned somewhere, that when you serve from localhost, you do not need SSL to install it. Knowing that, would have saved me the trouble of messing with apaches config and certificates.

So that was very frustrating as a start.

Much more helpful was a very simple hello world pwa which was barely installable. But it worked. And from there it was easy.

https://medium.com/james-johnson/a-simple-progressive-web-ap...


Thanks for the feedback! This is now the reference "first PWA" example: https://web.dev/codelab-make-installable. Let me know if you find it easier for new devs to get started with. The other codelab and a lot of other scattered content will be removed once we finish the migration to web.dev.

Please consider contributing to MDN. It's the best source for web development and it would be great to keep everything there, properly cross-referenced, etc.

Don't they already do that? They are part of the MDN Product Advisory Board since 2017.

Blog post of the announcement: https://blog.chromium.org/2017/10/building-unified-documenta...


The statement from b1tr0t directly refute that Google is contributing to MDN, as they put it: "Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev". As far as I know, web.dev is not MDN and has nothing to do with MDN.

Mentioned in another comment, but to be clear, our team contributes to MDN, and will continue to do so.

Web.dev is not an MDN replacement.


As another user mentioned, we do contribute to MDN. MDN is where we point devs for reference documentation. web.dev is for guides, how to's and other support docs.

Heh, you're asking a googler who's basically responsible for some of the actions Google is taking with Chrome, trying to make the web only browseable via Chrome and centralizing information under their own Google brand, to contribute to a cross-company/community effort (Mozilla + Microsoft + open source hackers)? While noble, I can only wish you good luck.

I think the sail has long sailed for asking Chrome/Google to help out with the openness/sharing on the web/internet. It's time we just start ignoring them instead.


Just want to note that you specifically mentioned Microsoft working with open source hackers in this comment saying that the ship has long since sailed on Chrome/Google contributing to the open web.

I don't know, never say never I guess. I'm certainly not going to defend Google's track record on openness and privacy -- there have been, under even the most generous of interpretations, huge missteps, and I don't think they deserve the benefit of the doubt -- but they do contribute. Edge backed by Chromium?


I was thinking about a particular announcement where Mozilla announcing that they are working with Microsoft on MDN.

Color me surprised when I discovered that also Google is mentioned there! Here is the announcement: https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-micr...

Reading that announcement makes b1tr0t's statement "We've started to consolidate docs under web.dev" even worse, as they previously said they are gonna contribute to MDN, but now they have turned and use their own shit anyways.

Screw you Google.


Our team actively contributes to MDN. Web.dev is not an MDN replacement, it's a channel for guides & other supporting documentation.

Just so understand correctly, you're contributing reference documentation to MDN but then everything else goes into web.dev? Why not contribute the "guides and other supporting documentation" to MDN as well?

As I understand, the Product Advisory Board for MDN was created with Mozilla + others in order to combat the fragmentation of information, but your actions seems to do the opposite.


More background services would be very nice even though it's a bit of a security nightmare. A request was opened almost 5 years ago for background geolocation services.

Any plans for https://developers.google.com/nearby ?

I don't want Google or central authorities to decide which PWAs are "trustworthy" directly to ask for certain permissions but there could be a way or compromise. I don't remember which feature it was but it required yes from Google.

I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them. It should be mandatory and important or may show a default screen with permissions and few dangerous ways they can be used for.


Background geo, including geofencing is challenging, but there may be a way forward. We're exploring this conceptually, but it's not in the plan for 2020. I'd certainly like to be able to improve the capabilities of web based ride sharing and similar apps that have a need for this.

Bluetooth discovery is an especially thorny area from a privacy perspective. What use cases did you have in mind?

Asking for permissions upfront has been found to be an anti-pattern in systems UXR. Research has found that users make better decisions and find the experience less interruptive when permissions are requested in context at runtime. For example, in a video chat app, it's better to ask for the camera/mic permission at the start of the first chat session, not when the app first starts. Mac OS, Android etc. and other platforms have all been moving in this direction over the past few years.

When the permission is requested, we're investigating ways that we can do more to communicate permission risks to the user. Nothing publicly shareable yet, but do expect experiments to be showing up in dev channels over the next few months while we try new things.


"I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them."

Wouldn't it make more sense, to display this info before you install a pwa?


Oh, yeah before. Though, I think it should also show that screen if a user hasn't used the app for a while.

Regarding your point on consumers, we put our PWA/TWA into the app store (for the reason you outlined) - and now get a raft of negative reviews that the TWA is the same as the mobile site... Which is frustrating, because that's the point.

Making it clear why a TWA is in the app store is hard in itself. Trying to explain why it's better for consumers over a native app + mobile site is even harder.

See these reviews for yourself here: https://play.google.com/store/apps/details?id=uk.co.openrent


> ... Consumers are another problem. ...

You blame Apple, Google and your consumers, instead of just making native apps. Why?


As an iOS and Android developer myself, this doesn't effect me but I still think Apple and Google making things harder for PWA is bad because Apple and Google are the gate keepers for what goes on their native app stores. I can cut some slack for Google as they at least allow third party app stores but Apple doesn't.

Either Apple should stop being the gate keeper or stop making life harder for web devs.


Maybe Apple could offer a compromise and allow users to sideload apps, but restrict non-App Store apps from accessing the file system or any kind of personal identification (like location etc.)

And improve their documentation to lower the barriers to native development.


Yep. Just because "PWA"-geek niche at HN wants to go back to shitty UX from 2004 it doesn't mean all tech companies or consumers want to.

I hope Apple keeps restricting this in the future too so that iOS app ecosystem won't turn in to a turkish fruit market full of crap like Android.


You’re getting downvoted, but I agree. Enough with shitty UX’s already!

So, make 3 apps instead of 1? This was the whole idea behind PWA.

Yes, that's the whole idea behind having different devices and operating systems with different capabilities.

Why should users suffer the lowest common denominator because of lazy developers?


I wouldn't attribute it to laziness. Quality can really suffer when you need to maintain so many code bases. Not all teams have those kinds of resources.

Perhaps Electron/PWA should be seen as a last resort, not the norm, reserved for exactly such a situation: when you don’t have the resources to build native for all platforms.

The lowest common denominator is not having the application available on your platform at all.

I'd rather them not have the resources to get an app working on my platform, then have enough resources to _barely_ get an app working on my platform.

It makes it a lot harder for solo developers or small companies to develop apps that work on all platforms

Why should customers pay for the development and maintenance of three apps when one is entirely sufficient for their needs?

"just making native apps"

Hiring aside, it’s probably simpler than attempting to reconcile souped up document viewers with contemporary expectations of “apps”, iOS and Android being purposefully built for the task and all.

Having done native Android/iOS and web dev, web dev is much easier than Android and at least on par/if not easier than iOS.

There's a bunch of very complex web/electron apps that disprove the idea that the web is only for static documentation and web-inspired ideas are coming to mobile (React --> Jetpack Compose/Swift UI).

More importantly, hiring can't be put aside, and it's much easier to adapt your web app to work for mobile (since websites should be screen size agnostic anyway) than it is to build a fully native app from scratch.


Makes sense, they want you to create native apps so they can collect their rent, and also dictate what is in, what is out, and control searching of apps.

> Consumers are another problem. They have no understanding of PWAs...

Really? You're blaming your customers for not being sufficiently tech savvy and not wanting what you're providing?

Personally, I am happy with Apple's decision here.


> There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.

Is it possible they also want you to port your app to the App Store to prevent an explosion of garbage and malware that could happen if PWAs really took off?


> to prevent an explosion of garbage and malware that could happen if PWAs really took off?

You mean, like the Internet. The App Store is a nice, safe walled garden, like AOL.


This is one of the primary value props of the platform.

And is anti-competitive and gives Apple and Google too much power over a device I own.

Value to whom?

To me, as a user of the device. Native apps can be a joy to use, websites almost never are.

Sure, but this is usually because of UX reasons and less because of performance or capabilities

There is absolutely no reason that PWAs can't be sandboxed like native apps, or even more aggressively. In fact, native apps are more likely to be spyware, as they can collect much more information from the user than a browser-based app can.

Native apps ostensibly go through review so that Apple can flag malfeasant behavior that is nonetheless allowed by the sandbox. Think things like a $999 purchase request that pops up on app launch (Yes, I know Apple isn’t that great at this. But that’s the argument that they use for review.)

It's not a good argument because I can find Bonzai Buddy-like apps on the Mac App Store, and they ban any GPL apps on their iPhone App Store.

GPL apps are not banned on the iPhone App Store.

Yes, they are[1]. The GPL is incompatible with the App Store terms and if Apple is aware that an app uses GPL software, they will reject or remove it from the App Store.

[1] https://www.zdnet.com/article/no-gpl-apps-for-apples-app-sto...


That link is from 2011, and the referenced verbiage is nowhere to be found in the App Store terms. I believe that the current terms leave the App Store open to GPL software. Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.

> I believe that the current terms leave the App Store open to GPL software

Please read the following:

https://github.com/nextcloud/ios/blob/master/COPYING.iOS

https://news.ycombinator.com/item?id=12827624

https://www.fsf.org/blogs/licensing/more-about-the-app-store...

> Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.

Developers of GPL software have had different experiences with Apple than what you're asserting. There is a direct incentive for Apple to police licensing incompatibilities if they are profiting from illegal distribution of GPL software on their platform.


> https://github.com/nextcloud/ios/blob/master/COPYING.iOS

I tend to think of this as reaction to GPL FUD; I know some people who have these so they never have to actually figure out the answer to this question.

> https://news.ycombinator.com/item?id=12827624

I have argued that a close reading of the TOS currently seems to allow GPL: https://news.ycombinator.com/item?id=21943994

> https://www.fsf.org/blogs/licensing/more-about-the-app-store...

Again, this is super old. Do you have anything newer?


I seriously doubt that. It's a lot more difficult to do horrible things with PWAs than it is with native apps. Apple has a history of doing everything they can to keep people inside their walled garden and this is just another instance of that.

This is really in response to the irresponsible use of APIs for trackers. Evercookie is a stunning example of how far it can go... From their repo:

- Standard HTTP Cookies - Flash Local Shared Objects - Silverlight Isolated Storage - CSS History Knocking - Storing cookies in HTTP ETags (Backend server required) - Storing cookies in Web cache (Backend server required) - HTTP Strict Transport Security (HSTS) Pinning (works in Incognito mode) - window.name caching - Internet Explorer userData storage - HTML5 Session Storage - HTML5 Local Storage - HTML5 Global Storage - HTML5 Database Storage via SQLite - HTML5 Canvas - Cookie values stored in RGB data of auto-generated, force-cached PNG images (Backend server required) - HTML5 IndexedDB - Java JNLP PersistenceService - Java exploit CVE-2013-0422 - Attempts to escape the applet sandbox and write cookie data directly to the user's hard drive.

https://github.com/samyk/evercookie

In short, everything and more can be used for tracking, and that has really killed the party for the many people who have created responsible, useful applications of these browser APIs.


It's really in response to a confused, ad-hoc web privacy model that has never been designed and is simply incrementally patched over time in response to complaints from an equally confused, directionless and visionless 'privacy warrior' subculture.

Mobile apps suffer these kinds of problems far less, partly because it's understood that actually mobile users don't install apps then get upset about "tracking", in fact, the vast majority of apps will want you to sign in to some sort of account and those that don't will be using ad networks to fund themselves, that users understand and accept this and that throwing up permissions screens doesn't achieve much because users will typically grant the permissions. Privacy on mobile platforms is more about stopping activity the average user would recognise as illegitimate spying - turning on cameras and microphones to feed conversations to angry ex-girlfriends, that sort of thing.

If the web's architecture had some sort of coherent view on how the tension between users, content providers and advertisers should work, then we wouldn't see this steady endless churn of app-breaking API changes. Everyone would know the rules of the road and there'd be way less tension as a result. Mobile platforms aren't quite there because they were designed with security architectures that were then pressed into service as ad-hoc privacy architectures, but they're still far more coherent on the topic than the web.


"some sort of coherent view on how the tension between users, content providers and advertisers"

Please share anything you think and find.

Balancing these kinds of trilemmas, on a knife's edge, is my metaphor for designing open markets, governance, democracy, planning, and so forth.


“... abusing over a dozen technologies...” is this a proof-of-concept or a real thing ? It just seems too horrendous to be real.

I think your comment really hits the nail on the head, IMHO the frustration shouldn’t be directed toward Apple but more toward the groups who have pushed the tracking practice so far to necessitate such draconian measures.


This is 100% correct. Being upset at Apple here is exactly like publishers whining about ad blockers when they should direct their frustration and anger directly at the ad creators (or themselves) for foolishly abusing their audience.

No, the two are different. Ads are only used for ads. localStorage has lots of uses, tracking users being only one of them. Apple is throwing out the baby with the bath water. Ad blockers merely throw out bath water with varying levels of dirtiness.

This is real, but also not new (as you can tell from the name check on Flash, Silverlight and IE). They used to be called "supercookies", but that term has come to mean something else in the last few years.

You could permissionwall that stuff, just like iOS asks for permissions to ask your location. If a random website wants to mess with Local Storage I know that I need to turn around.

... however i'm afraid that 99% of all users (the non-techies) would just be annoyed by the popup and click "OK"

Yes, that would have been a much better approach. It would hinder trackers, but not valid uses of localStorage.

I really appreciate this link. I would have never seen this otherwise. It's kind of a disappointment for us on the enterprise side. Our main offering is an offline app where people are disconnected from the internet for weeks and we use localStorage to validate who they are. It's a bit vague about how this affects apps that don't use safari. Nevertheless, we might have to start to really think about the user experience here now that this update is out.

To be honest, HTML5 LocalStorage was always different on iOS when compared to other platforms. The iOS browser localstorage is stored in /caches so it is cleaned when the device goes low on disk space. I found out the hard way, had a cordova app which ran on Android and iOS (and web) and saved an account token in LocalStorage. Some iOS users kept on getting logged out, mostly users with smaller size iPhones!

Now we store the account token in iOS keyring and that works.

ref: https://stackoverflow.com/questions/32927070/complete-data-l...


How do you use the iOS Keyring from within a PWA or website in Safari?

They already explained that they are using Cordova. This bridges native APIs to web apps. What you deploy is a native app through the app store.

Right, but Cordova isn’t PWA.

Sure! In a PWA, storing login tokens in the keyring would not be possible. So as I said, on iOS the localstorage (and cookies) would be cleared in low disk space conditions anyway. So the PWA experience was already not good!

Webkit's website says: "[..] deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site."

It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.


User not coming to website 7 days can't be invalid use-case. Losing important data simply because someone went on vacation is unacceptable.

Not allowing important data to be downloaded for cold storage is unacceptable.

Ok, allowing, then what? I still don't want to deal with export/import as a user.

You want all your important apps to migrate to a platform where their data is all tucked away in inscrutable filesystem locations that don't expire ever?

I have a few suggestions in the comment section you may or may not find agreeable.

With all due respect, this comes off as apologizing for Apple's disagreeable design choice.

If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful. Your suggestions might as well be aimed at browser vendors, who could conceivably offer user friendly controls for local storage (e.g. import/export without the dev panel). But as is usually the case each of the browser vendors has these little annoying ways that they cripple the browser to protect their business models. Apple is no exception to this. Look at how they've hampered the WebGPU process. Look at the history of their PWA support.


I strongly oppose Apple's anti-consumer practices in their App Store policy, PWA policy (non-existent) and similar places. I just believe this (localStorage policy) is not one of those cases.

Agreeing with Apple's disagreeable design choices isn't an apology, it's an honest opinion. If these choices are disagreeable, which I believe they are, they must be also agreeable by definition.


There's one simple thing that Apple could do. Do not delete local data if user bookmarked page from that website (or pinned it to home screen for mobile devices). Now bookmarked website treated like an "app" with slightly less restrictions and some random website data will be eventually purged (although I believe that 7 days should be extended to few months).

This is a great idea. Long forgotten bookmarks now has a purpose. I wish someone pitched this to all browsers out there.

> If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful.

Not if the features allow for increased web tracking.


I don't think that web tracking must be fought at expense of user UI. It's fine to fight web tracking by introducing measures that don't break honest websites. It's not fine to fight web tracking or anything by crippling user experience with honest websites.

> Not if the features decrease the need for the App Store

Fixed it for you. It's all about profit.


So store this data on the server.

But wouldn't that make it have less privacy? Now my webapp cannot be used offline and anonymously, user has to be logged in and tracked

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.


I have an old HTML5 game I made that stores a high score in localStorage. I might have to figure out an alternative solution later down the road.

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 (libraries like jQuery CDNs and whatnot are still a minor risk, particularly from a privacy perspective, but not as bad, although I never saw the point with the large variety of versions).


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

It doesn't change the status quo. Important data wasn't put in cookies before, and it wont be after. It was always a recipe for data loss.

Server side, or if you need privacy, have the user export to / import from a local file.


This is also about IndexedDB. Imagine native apps had all their data wiped if you don't open them (with an active internet connection) every 7 days. Not just on an iPhone, but also on macOS.

The big difference is native apps require explicit user content to get installed, while localstorage can be used by any website without user consent.

If browsers asked approval before using localstorage, we wouldn’t have this decision.


Apple is actively refusing to implement the standard for installable webapps (PWA). So, Apple is intentionally crippling a feature on the grounds of privacy with no possible remedy.

This decision comes from an actor that is protecting their business interests. It might have some positive side-effect for some users, and of course Apple will spin it that way. But in the end Apple is very agressively hampering the web's progress to get their sweet 30% cut.


Can you link me to a standard? I checked the W3C, and other than the disparate API's used by PWA's I don't see a "PWA standard" anywhere.

The standard is called "web app manifest". You can find it at https://w3c.github.io/manifest/.

Note that Apple does support PWA to some degree. My understanding is that they don't support onbeforeinstallprompt, which means you can't create an ergonomic, in-browser installation flow. You have to manually go in the browser menu to find an "Add to Homescreen" button, or something along those lines.


Installation of web app performed by bookmarking it or by pinning it to home screen. That's performed by explicit user decision and must be honored by browser if it wants to make a distinction between random website and useful website.

Not sure about pinning, but bookmarking should not grant any extra rights. Even the useful websites should not be able to track me forever.

Look, we already have lots of website prompts, like camera and location. The best thing, privacy-wise, would be an explicit prompt: "this website wants to store information, possibly including tracking identifiers, forever. Allow?"


This impacts an app I've built for reading academic papers but I imagine the work around here is to write to a file periodically and then load the file in if you don't detect indexedDB having the data you think it should. Obviously this has error cases all its own and makes it more difficult to manage but it doesn't seem like Apple is killing it to me, just making us jump through hoops and add extra complexity. Don't mistake me though this seems like an anti-competitive move from them to prevent people from circumventing the app store.

I apologise for being rude, but IMO you didn't build an app, you built a web page. Web pages are things people look at one time or maybe many times, but they are just web pages that exist in a web browser for the lifetime of the tab they're in, and then they're gone. They shouldn't expect to have any persistent storage from the browser, and if the browser does make small affordances for storage, it's not reasonable to have that persist indefinitely.

Apps are bundles of code/assets that people choose to install on a computer because they want to use them over time to do something. They have a clear lifecycle of installation and deletion that the user has complete control over.

I know the web app, PWA, offline app, etc. stuff is very popular, but it will never be as good as native apps, and it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle, but I would still honestly prefer that people just write a native application.


I really liked the web when it was just documents.

> you didn't build an app, you built a web page

"Progressive web apps use modern web APIs"

The word application is there twice. I don't have to like it.

> they are just web pages that exist in a web browser for the lifetime of the tab they're in

Evidently not. My opinion doesn't matter.

> They shouldn't expect to have any persistent storage

2016 "With Chrome 52, we're introducing the ability to make storage persistent"

> ...a clear lifecycle of installation and deletion that the user has complete control over.

I've never asked for 7 days

> it will never be as good as native apps

I don't develop anything for walled gardens. I cant wait for my linux phone.

> it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

This already happened. Again, I don't have to like it.

> I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle

But the user isn't given control over the life cycle. It's 7 days. No one asked for 7 days. It's just about short enough to be completely worthless?

I propose an interface where the pwa provides a picture of a cartoon animal, have fire at the bottom of the screen and each creature tumbling down at its chosen speed. Some 1 day, some 30, some 6 months. The user can opt to drag it up to save it. Notify the user with a soft screaming sound.

This is how it should work!


> have the user export to / import from a local file.

Exporting to local files does not work on iOS if the app has been saved to the home screen (it does work if it's loaded as a normal web page). This is likely a bug, but that's the way it is right now.


If it’s your app how not being tracked is an argument ? I mean you just can just not track him (unless I’m not understanding your point)

Of course, I can make my backend service well-behaving. But offline first is privacy by default, which I'd argue is a better approach.

Cool, so now my movie library app has to host terabytes worth of movies and deal with copyright laws, just because Apple assumes that anyone using IndexedDB must have malicious intent.

Would make our app non functional for users who have limited internet and also a huge burden of responsibility to store their data securely. We’ve always avoided hosting data as that’s a completely different ballgame.

The original comment referenced an app where the users are offline for weeks at a time. Storing data on a server is not really possible in this use case.

You say that as if it isn’t an absolutely giant extra piece of functionality and ongoing cost. That native apps won’t have to do.

Yea, we actually don't use safari at all in our app. So this might not have an effect but it's pretty vague.

If you don't use Safari you can patch webkit to change the policy, right? Change 7 to 10000000

Apple only allows apps to use their webkit implementation.

Even for other browsers. Chrome, Edge, Opera etc. on iOS all use webkit under the hood.

You could...but it's a change that the Webkit project would never accept and you would be forever diddling this value every time an update came along.

Sisyphus says 'Hi!'


Yeah I've got a lot of users with very shaky internet and intermittent involvement with a given application (not using it for a month, more). This presents some serious challenges / impossibilities for those user's use of a web app when they're not online.

I hope they come up with some good options as this news settles. It's hard to see this as anything but even just a accidental push ('well you should always have written an app for the app store') to force folks to write a native app / participate in the app store.


If you're using Cordova or Capacitor this is why, at Ionic, we recommend never using localStorage for storing important data. Better to use an explicit filesystem storage solution like SQLite.

Yeah, as far as I understand, cookies is the only storage method that will be left to use for long-term storage of user data. If I'm wrong, someone please correct me.

Edit: getting downvoted without any reasoning provided, so I assume I'm incorrect, there are more/less ways of storing data in the future for Safari users?


Not sure if this answers that, but: https://webkit.org/blog/8613/intelligent-tracking-prevention...

Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.


Cookies expire in the same way.

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 but will instead continue to work as normal (except for the fact that 3rd party cookies will stop working, which is a Good Thing)


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

Does this mean I'll soon be setting up an dummy "cookie maker" endpoint on my server that turns XHR body data into HTTPS cookie data as a workaround? :/

Interesting, I did not know that. Thanks for clarifying!

What if you have a cookie set by http and try to update it with js? Will it self-destruct now?

Technically, when you update it via js you're overwriting the existing cookie with a new one. And, from my understanding, it's then subject to the same restrictions as any other cookie set client side.

So in order to have a long-lived cookie, you essentially need to treat them as read-only client side, and push any and all update/write logic to the server such that it'll return a set-cookie header with any changes you require.


I would guess is works, but expiration is capped at today + 7 days.

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

great, sounds like we‘ll get to consent to storing cookies more frequently - everybody loves these banners. there’s even more fun to be had, thanks to GDPR dialogs with 73 nested toggles.

Have you considered porting to a native application?

I've considered just not supporting iOS.

IMO it is completely unacceptable to have a persistent permanent non-expiring store in the browser. The potential for abuse is too high.

Then why are first-party cookies okay? FTA:

> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.


Unexpiring cookies shouldn't be okay either.

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.


You don't need a dedicated developer to ship a WebView app. That's the whole selling point behind tech like Cordova. Most of your code can stay the same and most likely all of it will stay Javascript (or whatever you are transpiling to it).

Again, if you are actually affected by this issue right now, you have a web app that is more or less trivially ported to a web view app. Your user don't have to migrate, they already have accounts, they just need to download the app again, this time from the App Store.

> In a nutshell, it is the same reason why Adobe won't port their apps to Linux.

Linux is a non-market for Adobe apps. On the other hand, if you have an offline PWA right now, you most likely already have iOS users that you would probably lose if you start confronting them with this "7 days and your data is gone" bullshit.


Why is nobody mentioning that distribution of apps is behind apple's doors and they can stop you from distributing anything they don't like or want for any reason?

On android, you can side load apps. On iOS, you can't.

You have to pay 30% cut if you are doing payments.

You have to adhere to their reviews and design guidelines. Which is OK but not ok if you are a small team and your users are fine with somewhat lacking app.


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 systemically hindering web apps, especially on ones that are good on iPadOS, in order to boost native apps.

(I’m not saying this necessarily the start of this, but I am saying I'm not surprised. This is exactly the type change, targeting the exact type of app I’d expect to be targeted.)

[0]: https://blog.robenkleene.com/2020/03/20/ipadoss-new-mouse-su...


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

As a web developer, I've never believed Apple has hindered web development on their platform, purposefully or not. They just don't spend their resources adding in WebBluetooth or whatever new API-of-the-day Google has decided to come up with.

As I see it, their focus is on the user, which is why they've been slow to adopt APIs that are privacy concerns, or drain battery, or have other negative implications.


That’s a very rosy way of looking at it. iOS has had bugs with its “add to home screen” webapps that kicked around literally for years. If they were being “user first” they’d support it fully or not support it at all. Instead they implemented then neglected it.

All parts of Apple's platform has had bugs that have kicked around for literally years. Their native SDK is infamously under documented and has all sorts of bugs https://twitter.com/caseyliss/status/1171778706878160897

The bugs in Apple's software, whether in web or native or in documentation are not part of some nefarious plot, its just a part of Apple's mismanagement and relatively minimal resources.


> relatively minimal resources

Uh, they're the most well capitalized corporation in the world (or hovering in the top 3 plus or minus a few quarters). They have the resources to make it work if they wanted. There are undoubtedly thousands of engineers, hundreds of managers, and at least a handful of execs, working for Apple, lurking in this HN thread today, not because they're unaware of their ongoing sabotage of web standards on iOS, but because they're completely aware of it and want to take the temperature on how their latest kick to the shins of PWAs is going over.


I’m fully aware of how much cash Apple has, but they’re known for having very relatively small software teams looking after whatever app needs updating that release.

I wouldn’t be surprised if Safari/WebKit was one of the larger teams within Apple dedicated to a single app.


Apple really does run with very small software teams. It's cultural.

You’re between one to two orders of magnitude off in you estimate of the size of Apple’s web technologies team.

Probably because Apple giving a crap about web apps was depreciated with the release of iPhone OS 2.0 and the App Store over a decade ago. I'd bet few users even use the "add to home screen" button outside of corporate environments that want to add a shortcut to internal sites.

Facebook messenger is good use case for web app, but zuck want's to track you so you need to install app instead...

Try sending an AR video capture to someone over the web, lol

I'm sure there's more efficient ways to send text messages lol

What bugs exactly? Been using this feature for years and have never had issues with it.

Until a recent iOS release they had a number of undesirable features that made them a bit inconvenient to use: they used UIWebView (instead of the faster WKWebView), they "restarted" if you ever left them, and generally had a number of other quirks.

To be fair, they've had bugs in iOS they've kicked around for years...

How many users even know or care about that feature?

How is that relevant to the conversation? If it is so little-used as to be irrelevant then the user-first thing to do would be to remove the functionality but Apple haven’t.

I can speak from personal experience that users do use it when you include specific instructions on how to use it. And it’s used in a number of corporate settings for installing webapps on an iPad.


As a web developer, I've never believed Apple has hindered web development on their platform, purposefully or not. [...] As I see it, their focus is on the user, which is why they've been slow to adopt APIs that are privacy concerns, or drain battery, or have other negative implications.

As another web developer, I find this entirely unrealistic. Apple's QoI even for popular new features like the HTML5 media elements was a bug-ridden mess for years before they fixed even basic problems. Conveniently, having managed to break the de facto standard for serving video on the web that had been working for years up to that point (Flash players), that left native apps as the only reliable way to do a lot of even quite simple things you might want to do with multimedia content. There is a deep irony that some of the breakage was because they were playing those media elements through effectively a separate plugin of their own that wasn't properly integrated into Safari and consequently broke other basic web behaviours like cookies.

At this point, the idea that Apple's motivations for the constant breakage and even severe regression of web functionality on iOS devices are entirely altruistic and for the benefit of their users is about as credible as Google and Facebook lobbying for privacy regulations because they want to decrease tracking on the Internet.


Just to be clear, Apple didn't kill Flash, mobile killed Flash.

Even on the Android phones that supported Flash, it ran like shit and drained battery. Apple just never opted into that experience.

This revisionist history, of seeing people wanting the proprietary Flash to come back, is crazy.


Just to be clear, Apple didn't kill Flash, mobile killed Flash.

I don't think that generalisation is warranted.

Apple refused to support Flash at all, meaning everyone who wanted to provide (among other things) audio/video content had to switch to the nascent HTML5 functionality, which was at that time and for some years afterwards inferior to Flash in almost every way except availability.

In that situation, it made little sense to invest in better Flash support on Android as it was presumably seen as a dying technology. However, there was no inherent reason why Flash couldn't have been improved to use less battery in the same way that the browsers themselves were, or that Flash could not have taken advantage of better hardware support on mobile devices for computationally expensive tasks like video decoding as this became available with newer devices.

This revisionist history, of seeing people wanting the proprietary Flash to come back, is crazy.

There's nothing revisionist in saying that people wanted A/V content on their sites, that Flash player had been by far the dominant way of providing that content up to that point, or that the then-new HTML5 alternatives were also very poor in quality and performance on mobile for several years afterwards.

Remember how for several years everyone with iPhones couldn't watch the videos on a lot of websites, and how excited people were when the big video hosting sites started adding HTML5 players and, in time, support for better codecs? Probably many of those people had no idea what Flash or HTML5 even were, so I don't suppose they did "want Flash to come back", but they certainly weren't happy that they couldn't watch videos on websites like everyone else.


> As I see it, their focus is on the user,

Oh and let me guess, they know better than me that I don't need this or that.

Let them suffocate inside their poisonous wall garden as the web gets richer and richer.


Be careful what you wish for! I don't for an instant believe that Apple's motivations here are purely for their users' benefit, but their actions do at least tend to have some beneficial effect on privacy. Letting them suffocate so Google's spyware-laden ecosystem becomes the only viable way to access the web on mobile devices would not be an improvement.

In my opinion only we ourselves can save ourselves from Google. By using things like AdNauseam and educating everyone and their dog about ad blockers.

I don't think the way to fix ad bullshit is to close down everything, I do think it's in opening everything and educating everyone. That way people actually win, not corps, as it should be.


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.


I would just point out there are very valid use cases for these things, i.e. push notifications are very useful to me (from certain apps). The problem is one of consent.

MacOS Safari autoplays YouTube videos with now way to disable...

Interesting. I can tell Safari to not autoplay videos on YouTube in its preferences, but that doesn't seem to do anything. Seems more like a bug on Safari's part and/or workaround on Google's part than anything deliberate.

Safari uses some sort of algorithm to determine whether you actually want the autoplay to happen.

For example I've noticed that if you play a video on a website during that session, it will allow autoplay from scripts on that page (not 3rd party) for the rest of that session. Same for unmuting an autoplaying video.

This is all undocumented though and through personal observations, as Apple seemed to stop posting Safari documentation years ago.


You mean Safari team accidentally forgot to test a video feature on a largest video website?

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.

Sure they can, Apple would still have full control over push functionality. Web or native doesn't matter.

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.

Blacklisting is a losing game, especially from the malicious sites most likely to abuse this. Notice how those malware and fake Chrome extension ads have a new URL every day.

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

Actually the guidelines specifically ban non-webkit rendering engines.

> 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.


At a minimum we can be thankful that Apple's rules force web developers to care about one additional browser.

Lucky us. We web developers really want to care about specific browsers like it's 2006 again.

IE6 must have been a great inspiration for Apple judging by their behaviour when it comes to Web.


Eh, I'm not completely sold on that.

One can always rely on cordova/phonegap type of app with a C++ plugin to address this issue.

Personally, not having web app storing large amount of data is a good thing.


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.

Remember, harming webapps is Apple's agenda because only they benefit from it.

On the other hand, the web is mostly open for all, so most people benefit from it, not just Google.


There's some irony that Apple forcing the use of Safari on iOS is creating a monoculture when, were the restriction lifted, everyone would be using Chrome.

> everyone would be using Chrome.

I'd be amazed if there were more than a tiny fraction of iOS/iPadOS users (of which there are hundreds of millions) who weren't perfectly ok with Mobile Safari for their everyday usage.

[I'm probably the "target market" for Chrome (backend, occasionally frontend developer) and there's no way I'd have it on my phone. I only suffer the GMail app because they've made IMAP usage of gmail unreliable.]


It doesn’t matter what users choose, devs would badger users into using Chrome for their own convenience. It’d be the return of the “viewed best in” badges from the late 90s and early 00s.

If so it would be because users chose it and it would also help keep Firefox in the game which important to the long term health of the web.

> Without it it could be just Blink everywhere at this point.

In what reality-distortioned universe is that worse than having a crippled web?


Please don't call anything that's not Blink "a crippled web".

I believe that OP is saying it would be preferable to have blink-everywhere than to have a deliberately-crippled Apple web browser with all other choices banned.

I'm the OP and I am a Mozilla volunteer. I prefer a web with many engines, I want it to have WebKit, Blink, Gecko and more.

Agreed. There is no choice with IOS: you choose the same WebKit that they've chosen, or Safari. One engine and version, or one browser using that one engine.

Android is a web monoculture too. Non-Blink browsers on Android are at <1%.

You can install any browser you want from playstore or outside of playstore. There are no restrictions on what you can and cannot have on your phone on android.

Yet non-default browsers on Android are non-existent. So in practice Android has the same web-engine mono-culture as iPhone. Given how successfully Google was able to ensure Blink domination on desktop and even more so on Android it is very understandable what Apple has done. And for me having at least 2 web engines on mobile is better than 1.

In what reality-distortioned world is that worse than 0%? Also, several of those Blink-based browsers include additional non-Google-approved features, like Mozilla's own Firefox Focus, Samsung Browser, Edge, and Brave. I'd hardly call that a monoculture just because they share the same lineage.

Then you also prefer not to have those options banned.

If this were true, how would you explain the recent improvements to Safari on the iPad that make it as capable as desktop Safari. Until last year Google Docs did not work in Safari on the iPad. Now it works very well indeed. The same is true of most web apps.

This particular move takes something that is possible in web applications today and makes it not possible in the future (offline capable frontend-only applications), making the gap between native applications and browser applications further, so developers who need to build apps that works offline on iPhone, will only be able to use Apples own technologies for doing so, in a non-cross-platform way. Which in general, is what Apple always been favoring.

Google Docs doesn't really work offline, so it's not impacted by this change. Could also be a change of heart from Apple, since their stance on web applications have changed before.


It could also be exactly what they say it is: a way to prevent the abuse of local storage for tracking.

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.

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

Isn't the new policy for local storage being copied from an existing policy for cookies? How can they switch to cookies?


> Now they will just use cookies instead

In the linked article it actually mentions that this policy is being widened from cookies to the rest of script-writable storage.


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.

It's both.

They could restrict these APIs to "installed" web apps via the web app manifest file, if they were to adopt that. Maybe they will in the future, but for now they've just made web apps far less powerful.


> Google Docs doesn't really work offline

It actually works quite well offline


This is a great point with a simple explanation: How good Safari was on iPad was irrelevant before mouse support. Before mouse support, we had apps made with UIKit, which is a touch-first app framework, competing with web apps, which are keyboard-and-mouse first. So UIKit apps won, because UIKit apps are better for touch. With mouse support, that situation becomes exactly inverted: In UIKit apps, the keyboard and mouse are secondary, so web apps have the advantage in being keyboard-and-mouse first.

So now that web apps have the advantage, at least when a keyboard and mouse are attached to the iPad, Apple is going to be seeking to tip the scales back in native apps favor.


We’re all speculating about Apple’s motivation, but none of us really knows why Apple made its decision. Perhaps it’s best to focus on the trade-offs—privacy vs. functionality—and not the speculative Kremlinology.

Respectfully, no. Learning software is a big investment in time and effort. Since I'm on Apple's platforms, because I think they're the best compromise for running the software I want to run, I am going to continue to speculate their reasoning to try to predict which software will be successful on their platforms in the future, because that's how I choose where to invest my time and effort.

I respect you have some other motivations here, but I'm not doing this for fun. I'm doing this because it's important to how I spend my most important resources: my time and effort. So no, I'm not going to stop speculating, the mere idea is laughable. Like buying an individual stock while having no opinion of what direction the company might take in the future.


Of course you are free to speculate, but my point was that we lack evidence of Apple’s motivations that would help us to make predictions of any value. All we can do is tell a plausible story, and without evidence your story is no more likely to be true than mine.

> In UIKit apps, the keyboard and mouse are secondary

Apple just added new APIs to support these.


The people who work on making websites function better on iPad are literally a 20 second walk away from the people who work in Intelligent Tracking Prevention–do you really think that they'd seek to undermine each other in this way?

Absolutely, do you have evidence they are talking and consulting with each other? Obviously lack of evidence isn't evidence either, but departments do things all the time that are at odds with each other in companies like Apple.

> Absolutely, do you have evidence they are talking and consulting with each other?

Firsthand.


Which is strange, because they're already under scrutiny for being anti-competitive WRT their app ecosystem. Having good support for web apps could've softened that case a little bit.

As a native app developer, I can live with this.

As a navive app/web/backend developer and most importantly as an iOS user I can definitely live with this.

We don't want filthy legacy webapp shit, but 2020 high quality user experiences.


As long as you start refering to the "i" in "iPhone" as Intranet and not ~Internet~ then we're cool.

My iPod Classic has no intranet or internet.

What does the "i" mean in that case???


iPod was that Harddrive MP3 Player that piggybacked on the MP3 download craze people were doing on the internet, obviously.

Ha! Thanks!

I had never thought of that!! I wonder if that same idea came into naming the iMac then??


I have nothing against hybrid apps. In many use cases, they are the best approach, and I have often declined business, in recommending them to others, as opposed to what I can do.

My post was not an attack on anyone or anything, and it was not being snarky. All I said was that I develop native apps, and that this policy does not affect me.

I like developing native apps. I've been writing native Apple software for 34 years. It's not really difficult; just different. I have also been developing "Internet" software, of all kinds (full stack), since before the WWW. Using Apple stuff. It certainly can be done.


The Internet Phone was the Cisco iPhone, not the Apple iPhone

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: