offline web apps are different than PWA. A PWA doesn't necessarily work offline, but more is independent from the connection / loading of it. I do think most PWAs do work offline, but doesn't mean it's a requirement to call it a PWA.
Similarly, an offline capable web app is not necessarily a PWA, as PWA carries a lot of features to it besides being offline capable.
An offline web app is a frontend-only application (just HTML+CSS+JS or less) that can be loaded from any medium (internet, usb stick, direct TCP via netcat or any other transport) and work in your browser without requiring a remote connection to allow usage of it's features.
So yes, this would mean it doesn't run the risk of ex-filtration or snooping at the transport layer, as the data never leaves the specific website context in your browser.
> I'm still not sure why more vendors don't make iOS PWAs to get around the App Store payment rules.
Because users won't use them. For users that don't have a technical background: if it isn't in the app store then it essentially isn't an app. For techie users: lots of us don't want web apps because of the power, memory, and bandwidth usage is often higher than a well written native app. The fact that there's a gatekeeper who has some control over what shows up in the app store is usually a feature and not a bug.
If there were big parts of the app ecosystem that didn't have native apps, then eventually users would find web apps. But that isn't the case. Think of anything and search for it in the app store and there's an app for it (including 2048).
> For users that don't have a technical background: if it isn't in the app store then it essentially isn't an app
I'm not convinced of this. If it has an icon like proper apps, and feels like an app, I don't think users are going to mind if it came from the App Store.
The question is whether the unfamiliar 'installation' process is too fiddly for non-technical users. I don't think it is. I figure a 10 second How to install our app animation would do the job.
I think this is a problem of their own creation - done in the name of simplicity which has outlived its usefulness, but to take it back now would be chaos.
A closed, curated app store gave less technical users the confidence to actually download software without concern that it would screw up their device. However, things which have a different model like web apps or system extensions (read: keyboards) were also put into the same distribution mechanism.
You can see why as it removes a barrier to using them: people just go the same place they've always gone to get software on the platform. They make no distinction between the native Gmail app and GIF Keyboard because the install process is the same and each are displayed prominently.
In reality, 3rd party keyboards and the like should probably be handled - from a UI standpoint - like they are on macOS, inside System Preferences/Settings, with no app icon on the homescreen, they simply aren't as important as full blown apps.
^ People will dispute this and that's really nice...but they're wrong.
Better title: Apple restricts tracking by limiting browser storage, which hurts my particular app.
Browsers need to be severely limited due to them running arbitrary code from the web. Doesn't matter if it's an offline web app. If you want more access, make a native app (with or without web technologies).
Apple doesn’t have an ad network outside of the little money it makes from ads on the App Store itself.
Also, Apple may want a cut of the subscription revenue but most companies who have significant subscription revenue, don’t go through Apple’s subscriptions payments.
Yeah, cause everything in the browser is free, right?
Clearly it's A LOT of money for apple. If they didn't care about the money then they would just allow it so everyone could avoid receiving payments using apple and giving them 30 %.
That still doesn’t answer the question. How many websites were required to be apps because of limitations of Safari?
What makes you think users would willy nilly put their credit card on every random website.
Everyone can avoid using Apple for subscriptions. There are existence proofs of apps on the store that require payments outside of the store - like all digital content from Amazon.
Most of the money that people spend on the App Store are from games and in app consumables. Especially since the major services like Netflix and Spotify don’t allow in app subscriptions.
Seeing that most major subscription services on the App Store are already forcing users to subscribe outside of the App Store, Apple isn’t getting a cut of subscriptions from the most popular service.
How many apps require a subscription and cannot be a web app because of limitations of Safari?
How many paid apps would be websites if it weren’t for limitations of Safari?
The moment you offer in-app payment, apple gets a cut. This goes as far as not allowing apps that link to payment outside of the appstore's payment system.
There is a huge number of cordova apps out there. These are webapps inside a native wrapper, to access exactly those features that are crippled in safari. Reliable storage, push notifications, and not much more.
ACloudGuru does not allow you to pay for subscriptions via in app purchases, Udemy allows both. A company can decide whether it is right for their business model to allow in app purchases exclusively or along side their own payment options.
Hulu for instance allows in app purchases for the regular Hulu service but not Hulu Live
Which in a current situation is running a risk to fall into Google's walled garden. It is not there yet but Google's working hard on subverting the Internet.
But browsers are severely sandboxed already. What the article is talking about is:
> deleting all local storage (including Indexed DB, etc.) after 7 days
which I can see how it might help privacy (since you could be tracked via local storage too) but also how it might break any potential web app that might need data to last more than 7 days.
> If you want more access, make a native app
But then, everybody will complain about yet another Electron app, right? Not to mention that you have to fork over $99 and go through the signing / notarization hoops that change from one week to the other.
I think in the name of privacy and security only Apple and some select few corporations will be allowed to make software in the future. macOS / iOS and Windows 10 are evolutionary dead ends in many ways.
* AdoptOpenJDK releases that were notarized some months ago are no longer accepted by Apple since they made the rules even more stringent. I had releases accepted by Apple that are not accepted today using the same AdoptOpenJDK binaries.
* Apple's notarization rules are not global. There's whitelists for given companies/institutions/apps/files which means the same dylib might not have to be notarized by a bigger player but will have to be codesigned by you.
The above happened to me in the span of less than 3 months I think?
Indeed, the scripts I use per se to do the notarization are about the same as originally.
Apple may have stepped up notarization requirements, but I never heard them be inconsistent across developers. Are you sure you submitted the same binary? Nothing different about the signing or bundle layout?
If we had to make non-electron, native version of our app, that would mean Windows[1] and Android, because that's where the current users are. Forget the rest.
Is that the future you want?
[1] And they would not be happy about that either. For many that would mean RDP or Citrix. They prefer webapp right now.
I think apple DOES want this. Core markets cleanly segmented are probably a better value prop to apple than everything working everywhere and users being able to freely migrate between platforms
It would only be citrix if it was made a native app. It is presently a web app, presumably because it was determined to be a better choice. You proposed that it should be a native app. It would be the customers that would choose Citrix, but they'd probably prefer web apps (if they're anything like my customers).
The deployment story is so much better for web apps, which is the main reason it seems to be so compelling for big enterprises.
Apple requires that all code-related assets for an app should be included into the app. So the app cannot just be a launcher that show a browser with a website.
No, Apple offers anonymous user credential technology. Server gets unique identifier and ability to authenticate with no actual user info. Server gets an anonymous redirected email for sending info to the user. Apple is the intermediary. Of course, you can choose not to trust Apple, but Apple already has my info and their business model is not predicated on tracking and advertising. I'd rather continue to trust them than spread my data across more orgs, but that's my choice. You might choose differently.
But that's a solution for a single OS, for a web page that should be cross platform by default. And it's not really a solution, just additional complexity to what was a solved problem.
I choose differently, but my choice may matter to you if I throw up my hands and say "Too much effort; if the user visits my site in Safari, I'm just going to toss up a banner page that says "this site does not work in your browser."
It's a power-play on Apple's part to intermediate themselves where their inter-mediation isn't necessary. And all kinds of customers (enterprise in particular) won't appreciate Apple getting a free "hi hello" signal on how much their company uses some service that leverages this scheme. Especially if Apple is a potential competitor to them.
Same. We momentarily considered adding Apple Login to our app when they changed the rules a couple weeks back, but instead we are removing all social login and migrating all accounts to (email/username)/password. Why?
Because a) it's even more code we now have to support, both in our apps even on android and on web -- a huge investment we are not prepared to make, and b) because for what we do, we actually do need to know the user is who they say they are (we offer the ability to contract a service between third parties, which means anonymity is NOT desired). I was never really comfortable using social login at all, for that second reason, but was pressed to by my peers; after Apple's shenanigans we came to the mutual decision that it was time to cut the cord. The login screen is already busy enough, we don't need yet another button. So we'll simplify.
For this latest change, it won't affect us much because I have always made it a policy neither to trust, nor to rely on, the data in Local Storage, and only to use it for performance boosting via caching. If data isn't there, it isn't there, and we go get it. This is largely due to historical reasons where browsers have always borked the LS implementation in one way or another, but it's beneficial now in that it won't really change anything for us.
I do feel for folks that are using it for genuine storage though, I know some apps that use it in order to AVOID storing private data on their servers, which will now have problems and be forced to reduce privacy in order to adapt.
This is definitely a power play on Apple's part to further weaken the web ecosystem. Device sales have been falling for years, they know their cash cow is their 30% cut on app purchases and IAP, and they aren't going to let the browser cut into that. Any "privacy" benefit in this case is purely incidental (and as noted above I believe it will do the opposite in many cases).
I'm interested. As a iOS developer I always found that user want to skip the login page soon as possibile, if there is an FB button they press it.
Do you have different experiences of it?
Web-wide analytics (and our own, which have almost exactly the same stats), show about 30-40% of users still rely on email/password (and that's actually growing, as password managers become more ubiquitous especially when Apple implemented the built in credential manager in apps and in Safari on iOS).
We're actually getting rid of social login in our apps. And we're not alone, alot of platforms I use have recently moved the same direction, and I think for the same reasons.
Google, Facebook, Github, Twitter logins proliferated because
a) the cost of implementing an auth system is high, and those offered a turnkey solution that was cheap and quick to implement. This is no longer true, there are lots of options now to host your own auth while federating the hard work to someone else (e.g. Auth0, Cognito, et al)
b) for awhile, people LOVED the idea of having "an online identity" and a single login everywhere. Over time this has not really panned out, because it's the prisoner's dilemma; for it to work, everyone has to do it (which is why G and F have tried so hard to get everyone to use them). But also, because privacy questions have reduced the shiny appeal of that scenario in the first place. Combine that with easy to use password managers now, and it's much less necessary.
Thank you. I think this is very often overlooked. "Consent" gets thrown around alot but most of the time people basically have no choice if they want to, you know, participate in modern society. That's one of the reasons why an open web is so so so important and why I think Tim Berners Lee is working so hard to try to bring some part of that back as the "online world" (apps and internet) become more and more walled garden.
If you are coerced into giving consent, it isn't consent, and most of the time if you're doing it so you can be part of the world around you, it is coerced, whether people want to recognize that or not.
Any time you see the phrase "implicit consent", it can be helpful to stop and ask how that consent could be withheld without changing anything else. If it can't be, then it's not really consent at all.
Wouldn't it be possible to retain the data with privacy by:
- Asking the user client side for a password
- Encrypt data as a blob using some symmetric encryption (AES)
- Push encrypted blob to the server with login attached
If you're using SSO the client authenticates and then can pull down the encrypted blob based on the SSO auth being valid. You can tie 2FA in however you wish. At that point the user is prompted for a "data" password for that particular site. Or would there be an easy way to build a pki/pin cert type of encryption to eliminate the password prompt? (I feel like this is essentially what Keyring!? would do but maybe not?)
Outside of implementation weaknesses which I feel could be mitigated by created standard libs to do this, what am I missing?
Bonus points for pushing the data diffs only or even a version controlled blob (data stored in a git repo where only the diffs are pushed in encrypted form).
Edit: Or how about a local hardware appliance for your network that stores all data like this encrypted and pulls from there.
It's very hard to verify that the data is indeed encrypted, whereas with local storage you can just monitor your network usage and see that no requests are going out. Hell, you could airgap your machine and have no problems with localstorage.
You can implement end-to-end encrypted applications e.g. with the subtle crypto API, though there’s always a debate of whether this really provides good privacy as the website owner or an adversary who can inject code can still change the JS and steal the data. Personally I think it’s still much better as the data at rest is encrypted and only the user can decrypt it. Now the problem is of course that if the user forgets his/her password the data is gone. To alleviate that you can again think up some schemes like encrypting the encryption key with an asymmetric scheme where the private key is kept secure by the website owner, but that then requires a process for securely using this key... So it’s possible but not trivial I would say!
> If you want more access, make a native app (with or without web technologies).
Browsers usually ask for an additional permission in this case which would be a good approach. Your post sounds like "browsers need to be severely limited, so if you want to watch video, just launch VLC". It does not work this way.
> Browsers need to be severely limited due to them running arbitrary code from the web. Doesn't matter if it's an offline web app. If you want more access, make a native app (with or without web technologies).
Native apps have the same problems too and such "severe" limiting of apps in web browsers still doesn't solve it. The only more or less privacy preserving model I can think of for native apps today is open source repositories with app distribution not controlled by app developers, like f-droid or repositories in various linux distros.
You have to send every change to Apple before the user can run the code. In theory, that allows Apple to do more checks than when the code is dynamically loaded from your web server.
Apple doesn't care if your app logs your usage to Google Analytics every 1000ms.
Besides, in the browser you have trivial tools like uBlock and the network tab. In native apps, you have to use mitmproxy just to see what the app is doing at all.
It's not "limiting browser storage", it's making browser storage expire. TFA's example is just some random app, but this essentially kills the entire concept of an offline-first web app, and severely hurts the browser as an application platform.
Genuine question: what makes native ad frameworks different here? They execute with the same privilege of their containing app so surely they’re open to similar privacy concerns. Shouldn’t native apps have their storage cleared?
OR maybe it's apple's responsibility to figure out how that usecase can exist without security flaws?
As a customer, I'm tired of devices functionality being limited coz "security risks". Functionality that is arguably superior to native apps apart from the security risk.
Wouldn't making it first party only cover it? I don't see how this has anything to do with privacy/tracking. webpages can still leave long term cookies. The only way this is a privacy issues is if 3rd party iframes can use localstorage but just like 3rd party resources have their cookies blocked so to could localstorage.
Otherwise this has absolutely nothing to do with privacy or tracking.
Making a native app is more complicated than making a webapp, especially if you want something cross platform. Browsers are now an universal virtual machine, what was the JVM years ago, and with webassembly we will se more and more things done in the browser.
The real 'write once, run everywhere' are webapps, a webapp doesn't care if you are using Apple, Windows, Linux, BSD, whatever, if you have a compatible browser you use the app.
Sure there is Electron (or React Native), to me it doesn't make sense, what is the point that every application needs to ship basically a browser? And still Electron apps need to be compiled and packaged for every platform, while with webapps you enter the URL in the browser and you are done with it.
Doesn't adding APIs to browsers not only to use the local storage but also to access the filesystem of your device (of course asking the permission to the user) make more sense?
Of course what really Apple fears is loosing the control of the apps that gets used on their device, now they control the App Store that is the only way to get apps on their devices (beside jailbreak), with webapps is different, since you can access them directly from the browser.
And the thing that is absurd is that the first iPhone didn't have the App Store since Apple decided that the only way to get third party apps was trough the browser, now they are aiming for the opposite thing.
My company created a web client for our chat software product around 5 years ago. The quality of our product has slowly deteriorated as browser vendors continually remove or restrict features that once worked fine. Just to name two examples: autoplay audio for chat notifications and tab throttling killing websocket connections and background timers. I understand bad actors are abusing these things, but they're breaking totally legitimate use cases.
We've been forced into an electron client and now urge our customers to ignore the web client. If we didn't have a small number of customers on Macs, we would abandon web tech altogether and build a native Windows client.
...and give apple their cut. Why not add permissions to webapps? Like location, or push notification... oh that's another feature that happens to be missing only in safari.
Just accepting these moves from apple as "in the interest of users" is naïve. Apple has a huge vesting in their appstore, and every webapp is a potential appstore-app that is some lost revenue.
I mean, maybe apple is right, and the web should go back to a readonly document-like format, like in the old days. Articles and links. Apps for everything else. But let's not kid ourselves that they do it purely in the user's interest.
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.
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.
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.
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.
I expect the browsers to expand to an OS level. I hope so in fact. I don't find you rude I just find your thinking to be in the minority, maybe not on this site, but certainly in the broader market. The web is one of the best distribution platforms for applications we've seen as far as widespread adoption is concerned and in terms of resource expenditure to develop and maintain it's much better than native applications. And no offense but I'm not going to spend the resources to cater to a tiny percentage of the market who care about using native apps vs going to a site / adding to the homescreen if I can iterate, build, release and maintain features much quicker without the general costs of native applications and the arduous publication process current walled gardens have. I also simply don't support what Apple and Google stand for with respect to their app marketplaces.
Beyond that the distinctions you make usually come from no true scotsman developers. I've built everything from OS emulator extensions to 3d graphics engines to web apps and as far as building things people actually use and benefit from outside of my own interests the web takes the cake. The low-level or native vs web issue seems overly self masturbatory to me. I build things to get used by people quickly and effectively, not show off my mastery of software development. I take pride in my craft but the only value in shipped software is the utility it provides to other people as evidenced by the number of horribly designed pieces of software that are pretty much ubiquitous in our daily lives now. I pride myself on pragmatism, good fundementals, and getting things done expidiently and native applications seem no where close to being the pragmatic choice from any of those standpoints.
Some of my favorite projects however are from people who have tried to merge the performance and memory characteristics + respect for end user systems of native applications with the speed of development and ability to quickly iterate of web applications. If they reach the threshold I believe won't unnecessarily delay the work I want to do from native development minutae, then I'll make your native apps.
But I think you should get used to web apps being here to stay.
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.
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?"
> 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.
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.
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).
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.
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).
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.
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?
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?
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)
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.
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? :/
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.
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.
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.
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.
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.
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!
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.
There's certainly a balance to achieve there. Too few permissions prompt and you lose control, and too many and you get desensitized or even worse annoyed at them.
Actually there is - firefox does it all the time. It's simple really - just add a new obscure configuration parameter and tada - the browser starts ignoring your dns resolution setting and automatically uses a preconfigured one.
No need for a prompt, obtrusive or otherwise.
I configured my Chrome to block sounds on all websites except for a few selected ones. Now if blocked website plays sound, I can see tiny icon in right of my URL bad. It's absolutely unobtrusive, yet I can enable sound with two clicks.
Some browsers show an icon in the address bar when an app is requesting/can make use of an optional permission or feature. Clicking the icon allows you do grant the extra permission (i.e. allow cookies, enable, camera, etc.) but otherwise no additional prompt is shown.
I think this is an excellent example of such an unobtrusive prompt and is how ALL such features should be implemented. Sites should get almost no permissions by default and certainly not be able to show popup prompts.
That is not a prompt at all, just a fancy configuration option. Which most users will never notice and just assume the app is broken.
When the site tells them to "active X permission" without telling them how to (for their specific browser version), most will leave instead.
When the site gives super detailed, up-to-date instructions on how to activate the feature, a very large percentage of users will still leave instead.
When the feature is so useful that many sites go through all thouse troubles and it's common enough for users to encounter this that they'll follow through, most will do so for every site that tells them to and entices them with "ACTIVATE X TO RECEIVE YOUR $10,000 PRIZE, LUCKY WINNER!!!".
I would say yes. The reason being is that exceptions will be abused, so it is better to enforce rules that everyone has to follow than to depend upon good behavior which the people we are trying to stop won't (almost by definition, because we wouldn't be needing to try to stop them with rules if they were already respectful of the social contract).
If there were a way to enforce that the application has no access to any communication system (network, inter-app, maybe excluding explicit copy/paste), then I would be happy to give it permanent storage.
But as soon as you allow it any access to network resources then carrying state becomes a liability.
Even before this change, data in IndexedDB was kind of volatile - if a device was low on space, browsers could delete stored data.
https://dexie.org/docs/StorageManager describes the StorageManager API which lets you prompt the user to allow your IndexedDB data to be stored more reliably. My first thought after reading this article was wondering if this would allow an exception to the 7 day rule... but then I remembered that Safari is the only "modern" browser which does not support the StorageManager API
lol, sucks for users of my client side JS video game!
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't assume that people will always log in every week, in small businesses or design/manufacturing companies there are times when 2-3 weeks can pass without building new hardware or touching inventory.
I see two problems:
- apps with client-side-only data, i.e PWAs served from static sites
- delta sync, although useful, is little help when what the dev wanted was a fast start
Both your and Apple's concerns are valid. This change makes the fact (arguably) that these local storages are caches apparent.
Some web apps already saw the danger of having an easily purge-able storage on the client side and simply implemented an export function for their tools. I admire those tools more than the ones who overuse local storage for everything.
One such tool is draw.io, a flowchart maker. You use the app, persist everything in local storage and when you are done, you export your project into a file, all happening on the client side. When you need to edit, you import the file on launch. It's portable, it's protected from browser bugs/decisions and imho pretty user (privacy) friendly.
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.
With respect, I believe you are mistaken about what my important use cases are like.
Not going to go into details, but that JavaScript, CSS and fonts are all immutable assets, never to be requested again, while the database is significantly larger for clients who run their businesses using this software.
I have a copy of my “DAT Shopping List” demo I last opened about 6 months ago saved to my iPhone home screen... I opened it, and the data was still there. I’ll be really sad when I open it again after iOS autoupdates and the data will be nuked.
> The problem is that the users are so brainwashed from decades of Marketing.
Is there any other device or ecosystem of devices where my parents can fix their problems by turning it off and on? The fact that I have 80 years old grandparents who can’t read English using iPads and iPhones is not just marketing, that’s “not having to google and download malware bytes and ccleaner and go into regedit” to maybe fix issues.
My dad downloaded a bunch of malware on his one plus. I refused to waste my time helping him uninstall it (he feels that it’s his god given duty to click on everything, and the shadier the source, the more click worthy it is). So he tossed it and got an iPhone. Now he can click all he wants.
Also android doesn’t have any tablets comparable to iPad, and they don’t or didn’t have any video call app as easy to use as FaceTime. Although, whatsapp video may be just as good now, but I have a few grandparents and a great grandparent who don’t have phone numbers, so FaceTime works better in our family.
Also, we use our devices until they die. So we need them getting security updates as long as possible, which doesn’t happen on Android. We have 4+ year old iPhones and iPads being used, all pretty much up to date on security updates.
My point is whatever marketing Apple does, the product is clearly superior in many ways so it’s ridiculous to claim people are just “brainwashed”.
Most of us have caught onto the scam promises of ongoing support from android device makers. With an iphone you are pretty sure of 3-4 years of good support. Doesn't the latest iOS support the iphone SE? And I think iOS 12 is still getting updates (Jan 2020).
Are we absolutely sure they don't just mean the localstorage containers that aren't part of the current domain? In the same way they are clearing cookies from a different domain, and not the ones that belong to the current domain.
Yeah, if you look at the section in question, they're talking about this: "However, as many anticipated, third-party scripts moved to other means of first-party storage such as LocalStorage."
Basically, the ad tech/tracker folks were using first-party site storage to store identifiers, which is what Apple's trying to protect against.
The argument would be stronger if the post got into what privacy protection in Safari isn’t available in the Apple News app. Instead there’s a seemingly random plug for a content blocker app I’ve never heard about, which upon further inspection happens to be sold by the author.
Why not let users give access to that one site use data older than 7 days? So data stays but its only being deleted if you click that it can access (first time only - next time it remembers)
Safari already was lagging behind Chrome, Chrome forks and Firefox in a lot of feature adoption. This will only make it more of a "new Internet Explorer", a browser that sites recommend you NOT to use.
Lol, 50GB unexplained mobile data consumption. That'd be 3 months worth of rent on my mobile data plan. Good luck ever getting out of debt if that happened on some more expensive international roaming.
By Gordon Kelly, who gained notoriety for his "nasty surprise" set of iOS articles he'd put out whenever there was a new iOS update. Glad to see he's still at it.
Normally when one said "the new Internet Explorer" he meant "the browser that was always recommended to use", "the browser that stopped innovation because it was almost the only one used".
I think it is worth noting that you can really say "Apple" is doing this or "Apple" is doing that with decisions at this level.
The company is just too big and not working in unison.
The Apple Safari Team is killing/hurting offline apps. The author asks why they don't take the same approach in Apple News - as if it is the same team that is in charge. Different team with different priorities and likely not talking to each-other.
I think the larger point is valid - but it better to understand that this isn't some cohesive cross-company strategy at play. Its size-able teams working on their own priorities within a larger roadmap (presumably).
As Apple is one of the most closed companies, it's hard to put blame on anything Apple-related as you don't really know who the teams are. Sure, WebKit contributors are visible as it's an open source project, but who is the "Apple Safari Team" really? And who is the "Apple News" teams?
Easiest is just to put blame on the top-level entity, which is Apple. They have control over their teams so they can redirect the blame if they feel it's needed.
And if this change is to be able to force more developers to build native apps on their platform, then it's for sure a cohesive cross-company strategy. But we don't know if that's the case.
I love these types of comments. They contrast very well with the “the reason Apple makes great products is because their hardware and software teams work so closely together to bring a cohesiveness that other companies can’t” comments.
Sure it can be forked, but the problem is the millions of devices running Apple's version of Safari/WebKit on iOS without any say in it except switching to Android.
Sure, so maybe WebKitGTK will (if this applies to that version). But why would Apple choose to include this fork over their own version in their OSes? If they don't how do you plan on using it with any Apple OS?
I have many useful files in my computer, which I don't want to be deleted. You are saying, that it is ok, if the OS deletes all files in my computer from time to time.
A local storage is the only way webapps can store any data in your computer (other than asking you to manually load / save some configuration file). Not all webapps can afford cloud storage for all user.
I am not saying that it is OK to delete all your files. I am saying it has always been like that in the case of a browser's local storage.
As I said, that use case was out of the window long before. From the start, as far as I know.
No browser has ever given you any definite promise on whether your local storage data will be kept. That's also true for IndexedDB. So you need a mechanism to restore that data, be it cloud storage or something else.
If you wanted to support Safari private browsing, you even had to deal with local storage not being available _at all_.
There should also be an reliable upgrade mechanism, so the app alway upgrades successfully and completely, no intermediate states where a network or other error would prevent offline functionality from working.
I disagree. The IndexedDB was introduced as a permanent way to store data (which is not deleted after closing a website). As it is the only available standard for permanent storeage, I think it should be deleted only if the user asks to delete it (the same way you delete any other file in your computer).
Of course, browsers are free to do whatever they want. But the user can (and will) switch to the software, which does what he or she wants.
You disagree with the status quo implemented in browsers or you disagree with the decisions that were made years ago (by browser vendors), because you basically cannot guarantee for that (disk full, privacy settings, private browsing, etc.)?
It's different if there is a technical limitation (disk full - computer tend to barely function in this state anyway), or the user has opted in to ephemeral storage. But to not give users the choice to store things permanently is quite a severe restriction.
There is no guarantee that the data will be persisted permanently. Users can erase it by mistake easily using privacy settings. There's also quite ambivalent size restrictions. And last but not least, Incognito mode, which also is implemented in a number of different ways in practice, depending on the browser.
Basically, you cannot be sure that you can use it to persist data at all.
Size restriction will cause error at write time, it won't silently delete data. User error is user error, that's it. I know user who was deleting files in his Windows directory to free some space. Incognito mode is not intended for web apps usage, it's more for porn and things like that, I don't think that it's very relevant.
It works for majority of standard cases and when it does not work, user will receive error message, so he'll be aware. Not the case for Apple devices anymore.
I absolutely don't have that expectation. I built a comic reader app that I use on my Android tablet, which saves files to IndexedDB. I've been using this for over a year and no files have ever been deleted, even after I stopped using the app for a month or so.
If Apple provided an alternative this would be ok. An alternative such as the native file access API (still a WIP). Or a prompt so that the user can allow long-term storage. Or supporting the web app manifest so that users confirm they want to "install" a web app, granting it greater permissions.
But they've offered no alternatives here, that I can see. They've determined that client-side web apps are simply not important.
Hint: they are a for profit company and want you to pay 30% of your app revenue. Don't expect any open web standard that can actually compete with native apps unless something in the market changes.
Except for iPhones/iPads where you don't really have a choice. Also most people don't give a shit which browser they use, they just use whatever browser is available when they get their device, which makes sense. But those users might soon have their data removed without really understanding why.
So I guess more people will switch from iOS to other devices.
I am the creator of a photo editor www.Photopea.com and I see, that more and more people care about their browsers. They spend a lot of time discussing the issues of their browser with me, because they need to do a serious work in it.
It's not super clear but, if I'm reading it correctly, the 7 days are 7 days of use. So if you don't open the site for 3 days, the counter is still at 0.
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.)
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I'm an engineer at a platform that makes it easier to build privacy-friendly apps. This means that all apps on our platform have app-specific private keys stored on the client side (in localStorage), and they never touch a server.
With this change, you're essentially "logged out" after 7 days of inactivity.
This is pretty a bad user experience. I honestly am not sure how to mitigate this. MacOS Safari might not be a massive market, but iOS Safari is.
Any thoughts about how we should address this change?
Being logged out after 7 days of inactivity could be a little bit annoying but I can live with that, as long as I can log in again.
I could be misinterpreting your comment but are you saying your keys are simply destroyed upon this “log out”? Then I’m not really sure why your platform was considered working in the first place, if it’s tied to a specific browser of a specific device and won’t survive a clearing of storage which any user can do at any time for a variety of reasons?
No, it's not tied to a specific device. You can of course log back in, and keys are not "destroyed". We ask users to store a 12-word seed phrase, from which all other keys are derived from.
What if someone accidentally erases everything because that’s what they’re told when something doesn’t work right? Answer: it’s volatile storage in the first place, and a tiny one at that. Heck some browsers can be configured to erase everything when closed (when operating in non-incognito/private mode).
> Heck, they could even go further and ban apps from corporations like Facebook, Inc., and Alphabet, Inc., that have violating your privacy as the core tenet of their business model.
If Apple were to ban the Gmail app (and obviously block web access via iOS too because that would be a loophole otherwise), I would throw away my iPhone, swear off business with Apple, and search dearly for a way to sue them.
I don’t love the walled garden iOS represents, I merely live with it in exchange for great hardware and UX. If the bargain changes to be more restrictive, I would turn against it in a heartbeat.
Thinking about that, is no surprise Apple is striking out early to make web apps useless. If they wait too long, they will become entrenched, and people will feel like they have lost something if access is restricted. Apple really wants to jealously protect its control, and more importantly ability to take 30% tax of every transaction that they can perceive.
The article doesn't exactly cut to the chase. Here it is:
> "...But deleting all local storage (including Indexed DB, etc.) after 7 days..."
From the Apple announcement:
> Now ITP [Intelligent Tracking Prevention] has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site. ...
I'm confused, or seeing confusion, over some things in the comments here. "We don't use Safari in our app..." We're talking web apps: you know, web sites with functionality. You don't exactly have control over which browser your users use. And in iOS, everyone is using 'Safari' even if it's Firefox or Chrome wrapped around the rendering control. This means you have to assume that the policy affects any visitor from any web browser on iOS. Technically, the other browser vendors can siphon the data into other storage to their users' benefit, but I don't know how likely they are to do that, nor whether Apple would approve them with such changes.
Do you mean that you deploy a 'native' app that's really just a wrapper around a web view that would also be just Safari? Same policy applies, but now, you have the option, in native code, to siphon off data and put it into Real Storage.
926 comments
[ 3.4 ms ] story [ 395 ms ] thread(edit Turns out that's not quite right, see diggan's reply.)
From the article:
> You’d almost think they had an App Store to promote or something.
There's certainly a tension here. I'm still not sure why more vendors don't make iOS PWAs to get around the App Store payment rules.
Perhaps related: Very roughly a year ago, something changed in iOS that broke the 2048 PWA. Its swipe-detection no longer works. A pity.
Similarly, an offline capable web app is not necessarily a PWA, as PWA carries a lot of features to it besides being offline capable.
So yes, this would mean it doesn't run the risk of ex-filtration or snooping at the transport layer, as the data never leaves the specific website context in your browser.
Because users won't use them. For users that don't have a technical background: if it isn't in the app store then it essentially isn't an app. For techie users: lots of us don't want web apps because of the power, memory, and bandwidth usage is often higher than a well written native app. The fact that there's a gatekeeper who has some control over what shows up in the app store is usually a feature and not a bug.
If there were big parts of the app ecosystem that didn't have native apps, then eventually users would find web apps. But that isn't the case. Think of anything and search for it in the app store and there's an app for it (including 2048).
I'm not convinced of this. If it has an icon like proper apps, and feels like an app, I don't think users are going to mind if it came from the App Store.
The question is whether the unfamiliar 'installation' process is too fiddly for non-technical users. I don't think it is. I figure a 10 second How to install our app animation would do the job.
A closed, curated app store gave less technical users the confidence to actually download software without concern that it would screw up their device. However, things which have a different model like web apps or system extensions (read: keyboards) were also put into the same distribution mechanism.
You can see why as it removes a barrier to using them: people just go the same place they've always gone to get software on the platform. They make no distinction between the native Gmail app and GIF Keyboard because the install process is the same and each are displayed prominently.
In reality, 3rd party keyboards and the like should probably be handled - from a UI standpoint - like they are on macOS, inside System Preferences/Settings, with no app icon on the homescreen, they simply aren't as important as full blown apps.
^ People will dispute this and that's really nice...but they're wrong.
It has become spam, just like news sites asking to send notifications.
One reason is because Apple have incentive to break PWAs and they will do it. It's not a wise business decision to act against big player.
Browsers need to be severely limited due to them running arbitrary code from the web. Doesn't matter if it's an offline web app. If you want more access, make a native app (with or without web technologies).
which is somewhat ironic, because the goal of a web app is to break free of the walled garden and become OS-independant.
Also, Apple may want a cut of the subscription revenue but most companies who have significant subscription revenue, don’t go through Apple’s subscriptions payments.
Clearly it's A LOT of money for apple. If they didn't care about the money then they would just allow it so everyone could avoid receiving payments using apple and giving them 30 %.
What makes you think users would willy nilly put their credit card on every random website.
Everyone can avoid using Apple for subscriptions. There are existence proofs of apps on the store that require payments outside of the store - like all digital content from Amazon.
Most of the money that people spend on the App Store are from games and in app consumables. Especially since the major services like Netflix and Spotify don’t allow in app subscriptions.
How many apps require a subscription and cannot be a web app because of limitations of Safari?
How many paid apps would be websites if it weren’t for limitations of Safari?
There is a huge number of cordova apps out there. These are webapps inside a native wrapper, to access exactly those features that are crippled in safari. Reliable storage, push notifications, and not much more.
Hulu for instance allows in app purchases for the regular Hulu service but not Hulu Live
> deleting all local storage (including Indexed DB, etc.) after 7 days
which I can see how it might help privacy (since you could be tracked via local storage too) but also how it might break any potential web app that might need data to last more than 7 days.
> If you want more access, make a native app
But then, everybody will complain about yet another Electron app, right? Not to mention that you have to fork over $99 and go through the signing / notarization hoops that change from one week to the other.
I think in the name of privacy and security only Apple and some select few corporations will be allowed to make software in the future. macOS / iOS and Windows 10 are evolutionary dead ends in many ways.
* AdoptOpenJDK releases that were notarized some months ago are no longer accepted by Apple since they made the rules even more stringent. I had releases accepted by Apple that are not accepted today using the same AdoptOpenJDK binaries.
* Apple's notarization rules are not global. There's whitelists for given companies/institutions/apps/files which means the same dylib might not have to be notarized by a bigger player but will have to be codesigned by you.
The above happened to me in the span of less than 3 months I think?
Indeed, the scripts I use per se to do the notarization are about the same as originally.
And I made a test about the non-global rules too (by trying to submit the same binary and getting rejected).
My notes are here: https://www.patreon.com/posts/34472331
You can take the same Apache-NetBeans-11.3-bin-macosx.dmg and see how you could submit it with your own key.
I guess there may be different rules on a .pkg vs .app in a DMG but it seems silly since the user gets the same bits on disk.
Is that the future you want?
[1] And they would not be happy about that either. For many that would mean RDP or Citrix. They prefer webapp right now.
The market will decide. Your comment is just on the user-hostile side of assuming it will prefer your technology choices.
The deployment story is so much better for web apps, which is the main reason it seems to be so compelling for big enterprises.
But the argument that this will protect privacy in the first place seems really weak.
Before this change in Apple's policy, an app could store my config data on my PC.
After this change, they'd need to have me log in and send the config data to their servers.
That seems like I've lost privacy, not gained it.
You'd have to log in. That's a hurdle that involves implicit consent.
It's a power-play on Apple's part to intermediate themselves where their inter-mediation isn't necessary. And all kinds of customers (enterprise in particular) won't appreciate Apple getting a free "hi hello" signal on how much their company uses some service that leverages this scheme. Especially if Apple is a potential competitor to them.
Because a) it's even more code we now have to support, both in our apps even on android and on web -- a huge investment we are not prepared to make, and b) because for what we do, we actually do need to know the user is who they say they are (we offer the ability to contract a service between third parties, which means anonymity is NOT desired). I was never really comfortable using social login at all, for that second reason, but was pressed to by my peers; after Apple's shenanigans we came to the mutual decision that it was time to cut the cord. The login screen is already busy enough, we don't need yet another button. So we'll simplify.
For this latest change, it won't affect us much because I have always made it a policy neither to trust, nor to rely on, the data in Local Storage, and only to use it for performance boosting via caching. If data isn't there, it isn't there, and we go get it. This is largely due to historical reasons where browsers have always borked the LS implementation in one way or another, but it's beneficial now in that it won't really change anything for us.
I do feel for folks that are using it for genuine storage though, I know some apps that use it in order to AVOID storing private data on their servers, which will now have problems and be forced to reduce privacy in order to adapt.
This is definitely a power play on Apple's part to further weaken the web ecosystem. Device sales have been falling for years, they know their cash cow is their 30% cut on app purchases and IAP, and they aren't going to let the browser cut into that. Any "privacy" benefit in this case is purely incidental (and as noted above I believe it will do the opposite in many cases).
1) I don't want social media to track me everywhere
2) If the people developing this app have taken this shortcut, what other bad, leaky implementations do they have on their site/app?
-> No thanks, exit this way
We're actually getting rid of social login in our apps. And we're not alone, alot of platforms I use have recently moved the same direction, and I think for the same reasons.
Google, Facebook, Github, Twitter logins proliferated because
a) the cost of implementing an auth system is high, and those offered a turnkey solution that was cheap and quick to implement. This is no longer true, there are lots of options now to host your own auth while federating the hard work to someone else (e.g. Auth0, Cognito, et al)
b) for awhile, people LOVED the idea of having "an online identity" and a single login everywhere. Over time this has not really panned out, because it's the prisoner's dilemma; for it to work, everyone has to do it (which is why G and F have tried so hard to get everyone to use them). But also, because privacy questions have reduced the shiny appeal of that scenario in the first place. Combine that with easy to use password managers now, and it's much less necessary.
If you are coerced into giving consent, it isn't consent, and most of the time if you're doing it so you can be part of the world around you, it is coerced, whether people want to recognize that or not.
- Asking the user client side for a password
- Encrypt data as a blob using some symmetric encryption (AES)
- Push encrypted blob to the server with login attached
If you're using SSO the client authenticates and then can pull down the encrypted blob based on the SSO auth being valid. You can tie 2FA in however you wish. At that point the user is prompted for a "data" password for that particular site. Or would there be an easy way to build a pki/pin cert type of encryption to eliminate the password prompt? (I feel like this is essentially what Keyring!? would do but maybe not?)
Outside of implementation weaknesses which I feel could be mitigated by created standard libs to do this, what am I missing?
Bonus points for pushing the data diffs only or even a version controlled blob (data stored in a git repo where only the diffs are pushed in encrypted form).
Edit: Or how about a local hardware appliance for your network that stores all data like this encrypted and pulls from there.
Browsers usually ask for an additional permission in this case which would be a good approach. Your post sounds like "browsers need to be severely limited, so if you want to watch video, just launch VLC". It does not work this way.
Native apps have the same problems too and such "severe" limiting of apps in web browsers still doesn't solve it. The only more or less privacy preserving model I can think of for native apps today is open source repositories with app distribution not controlled by app developers, like f-droid or repositories in various linux distros.
How's installing a native app better for a random user privacy or security wise, exactly?
Besides, in the browser you have trivial tools like uBlock and the network tab. In native apps, you have to use mitmproxy just to see what the app is doing at all.
I understand it's changing too, but not as fast as safari.
As a customer, I'm tired of devices functionality being limited coz "security risks". Functionality that is arguably superior to native apps apart from the security risk.
Otherwise this has absolutely nothing to do with privacy or tracking.
The real 'write once, run everywhere' are webapps, a webapp doesn't care if you are using Apple, Windows, Linux, BSD, whatever, if you have a compatible browser you use the app.
Sure there is Electron (or React Native), to me it doesn't make sense, what is the point that every application needs to ship basically a browser? And still Electron apps need to be compiled and packaged for every platform, while with webapps you enter the URL in the browser and you are done with it.
Doesn't adding APIs to browsers not only to use the local storage but also to access the filesystem of your device (of course asking the permission to the user) make more sense?
Of course what really Apple fears is loosing the control of the apps that gets used on their device, now they control the App Store that is the only way to get apps on their devices (beside jailbreak), with webapps is different, since you can access them directly from the browser.
And the thing that is absurd is that the first iPhone didn't have the App Store since Apple decided that the only way to get third party apps was trough the browser, now they are aiming for the opposite thing.
We've been forced into an electron client and now urge our customers to ignore the web client. If we didn't have a small number of customers on Macs, we would abandon web tech altogether and build a native Windows client.
that’s not been my experience*
* unless you use some huge web framework to abstract everything and patch all the differences between the browsers
...and give apple their cut. Why not add permissions to webapps? Like location, or push notification... oh that's another feature that happens to be missing only in safari.
Just accepting these moves from apple as "in the interest of users" is naïve. Apple has a huge vesting in their appstore, and every webapp is a potential appstore-app that is some lost revenue.
I mean, maybe apple is right, and the web should go back to a readonly document-like format, like in the old days. Articles and links. Apps for everything else. But let's not kid ourselves that they do it purely in the user's interest.
A big chunk of the web these days uses JWT and localStorage for auth.
It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.
Sisyphus says 'Hi!'
Server side, or if you need privacy, have the user export to / import from a local file.
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.
> 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!
Beyond that the distinctions you make usually come from no true scotsman developers. I've built everything from OS emulator extensions to 3d graphics engines to web apps and as far as building things people actually use and benefit from outside of my own interests the web takes the cake. The low-level or native vs web issue seems overly self masturbatory to me. I build things to get used by people quickly and effectively, not show off my mastery of software development. I take pride in my craft but the only value in shipped software is the utility it provides to other people as evidenced by the number of horribly designed pieces of software that are pretty much ubiquitous in our daily lives now. I pride myself on pragmatism, good fundementals, and getting things done expidiently and native applications seem no where close to being the pragmatic choice from any of those standpoints.
Some of my favorite projects however are from people who have tried to merge the performance and memory characteristics + respect for end user systems of native applications with the speed of development and ability to quickly iterate of web applications. If they reach the threshold I believe won't unnecessarily delay the work I want to do from native development minutae, then I'll make your native apps.
But I think you should get used to web apps being here to stay.
If browsers asked approval before using localstorage, we wouldn’t have this decision.
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.
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.
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?"
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.
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.
Storing JWTs, game state data, etc.
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).
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.
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.
Not if the features allow for increased web tracking.
Fixed it for you. It's all about profit.
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?
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)
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.
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.
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.
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.
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.
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.
> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.
Now we store the account token in iOS keyring and that works.
ref: https://stackoverflow.com/questions/32927070/complete-data-l...
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.
Actually, I'd be even happier if any form of offline storage required explicit user permission anyway.
network.trr.mode I'm looking at you.
I think this is an excellent example of such an unobtrusive prompt and is how ALL such features should be implemented. Sites should get almost no permissions by default and certainly not be able to show popup prompts.
When the site tells them to "active X permission" without telling them how to (for their specific browser version), most will leave instead.
When the site gives super detailed, up-to-date instructions on how to activate the feature, a very large percentage of users will still leave instead.
When the feature is so useful that many sites go through all thouse troubles and it's common enough for users to encounter this that they'll follow through, most will do so for every site that tells them to and entices them with "ACTIVATE X TO RECEIVE YOUR $10,000 PRIZE, LUCKY WINNER!!!".
Even offline storage that is only used locally? Say a game with savegames that has doesn't use online connection to play it.
Another example: a password manager.
But as soon as you allow it any access to network resources then carrying state becomes a liability.
https://dexie.org/docs/StorageManager describes the StorageManager API which lets you prompt the user to allow your IndexedDB data to be stored more reliably. My first thought after reading this article was wondering if this would allow an exception to the 7 day rule... but then I remembered that Safari is the only "modern" browser which does not support the StorageManager API
lol, sucks for users of my client side JS video game!
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't assume that people will always log in every week, in small businesses or design/manufacturing companies there are times when 2-3 weeks can pass without building new hardware or touching inventory.
If you put data in IDB, it will stay there for 7 days and then if it gets deleted the delta sync would just download it again.
Some web apps already saw the danger of having an easily purge-able storage on the client side and simply implemented an export function for their tools. I admire those tools more than the ones who overuse local storage for everything.
One such tool is draw.io, a flowchart maker. You use the app, persist everything in local storage and when you are done, you export your project into a file, all happening on the client side. When you need to edit, you import the file on launch. It's portable, it's protected from browser bugs/decisions and imho pretty user (privacy) friendly.
Not going to go into details, but that JavaScript, CSS and fonts are all immutable assets, never to be requested again, while the database is significantly larger for clients who run their businesses using this software.
I have a copy of my “DAT Shopping List” demo I last opened about 6 months ago saved to my iPhone home screen... I opened it, and the data was still there. I’ll be really sad when I open it again after iOS autoupdates and the data will be nuked.
https://github.com/jimpick/dat-shopping-list-tokyo
Evil company. How do we fix this? Shame users?
The problem is that the users are so brainwashed from decades of Marketing.
Is there any other device or ecosystem of devices where my parents can fix their problems by turning it off and on? The fact that I have 80 years old grandparents who can’t read English using iPads and iPhones is not just marketing, that’s “not having to google and download malware bytes and ccleaner and go into regedit” to maybe fix issues.
I've had to aid my parents using Apple devices just as much as Android (father likes iPhone, mother prefers Samsung Galaxy).
edit: so much for anecdotes...
Also android doesn’t have any tablets comparable to iPad, and they don’t or didn’t have any video call app as easy to use as FaceTime. Although, whatsapp video may be just as good now, but I have a few grandparents and a great grandparent who don’t have phone numbers, so FaceTime works better in our family.
Also, we use our devices until they die. So we need them getting security updates as long as possible, which doesn’t happen on Android. We have 4+ year old iPhones and iPads being used, all pretty much up to date on security updates.
My point is whatever marketing Apple does, the product is clearly superior in many ways so it’s ridiculous to claim people are just “brainwashed”.
That's a very US centric view. And even among those, most iPhone users aren't tech savvies.
EDIT: Clarification from a Webkit dev https://twitter.com/alexcroox/status/1242559843354972161
Basically, the ad tech/tracker folks were using first-party site storage to store identifiers, which is what Apple's trying to protect against.
https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-io...
You Apple users will put up with anything!
(disclaimer: iOS user)
The company is just too big and not working in unison.
The Apple Safari Team is killing/hurting offline apps. The author asks why they don't take the same approach in Apple News - as if it is the same team that is in charge. Different team with different priorities and likely not talking to each-other.
I think the larger point is valid - but it better to understand that this isn't some cohesive cross-company strategy at play. Its size-able teams working on their own priorities within a larger roadmap (presumably).
Easiest is just to put blame on the top-level entity, which is Apple. They have control over their teams so they can redirect the blame if they feel it's needed.
And if this change is to be able to force more developers to build native apps on their platform, then it's for sure a cohesive cross-company strategy. But we don't know if that's the case.
A local storage is the only way webapps can store any data in your computer (other than asking you to manually load / save some configuration file). Not all webapps can afford cloud storage for all user.
As I said, that use case was out of the window long before. From the start, as far as I know.
No browser has ever given you any definite promise on whether your local storage data will be kept. That's also true for IndexedDB. So you need a mechanism to restore that data, be it cloud storage or something else.
If you wanted to support Safari private browsing, you even had to deal with local storage not being available _at all_.
Of course, browsers are free to do whatever they want. But the user can (and will) switch to the software, which does what he or she wants.
Basically, you cannot be sure that you can use it to persist data at all.
It works for majority of standard cases and when it does not work, user will receive error message, so he'll be aware. Not the case for Apple devices anymore.
If Apple provided an alternative this would be ok. An alternative such as the native file access API (still a WIP). Or a prompt so that the user can allow long-term storage. Or supporting the web app manifest so that users confirm they want to "install" a web app, granting it greater permissions.
But they've offered no alternatives here, that I can see. They've determined that client-side web apps are simply not important.
I am the creator of a photo editor www.Photopea.com and I see, that more and more people care about their browsers. They spend a lot of time discussing the issues of their browser with me, because they need to do a serious work in it.
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...
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.
It is still a significant restriction, but it is rather understandable. Without it it could be just Blink everywhere at this point.
In what reality-distortioned universe is that worse than having a crippled web?
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.]
On the other hand, the web is mostly open for all, so most people benefit from it, not just Google.
Personally, not having web app storing large amount of data is a good thing.
> 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
IE6 must have been a great inspiration for Apple judging by their behaviour when it comes to Web.
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.
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.
Web push is better than native app push when it comes to power consumption as web push is stricter on what you 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.
What does the "i" mean in that case???
I had never thought of that!! I wonder if that same idea came into naming the iMac then??
We don't want filthy legacy webapp shit, but 2020 high quality user experiences.
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.
Isn't the new policy for local storage being copied from an existing policy for cookies? How can they switch to cookies?
In the linked article it actually mentions that this policy is being widened from cookies to the rest of script-writable storage.
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.
It actually works quite well offline
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.
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.
Apple just added new APIs to support these.
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.
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.
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.
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 wouldn’t be surprised if Safari/WebKit was one of the larger teams within Apple dedicated to a single app.
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.
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.
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.
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.
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.
Firsthand.
With this change, you're essentially "logged out" after 7 days of inactivity.
This is pretty a bad user experience. I honestly am not sure how to mitigate this. MacOS Safari might not be a massive market, but iOS Safari is.
Any thoughts about how we should address this change?
I could be misinterpreting your comment but are you saying your keys are simply destroyed upon this “log out”? Then I’m not really sure why your platform was considered working in the first place, if it’s tied to a specific browser of a specific device and won’t survive a clearing of storage which any user can do at any time for a variety of reasons?
Eg: in a classroom.
The difference is that one situation is controlled by the user and the other is not.
> Heck, they could even go further and ban apps from corporations like Facebook, Inc., and Alphabet, Inc., that have violating your privacy as the core tenet of their business model.
If Apple were to ban the Gmail app (and obviously block web access via iOS too because that would be a loophole otherwise), I would throw away my iPhone, swear off business with Apple, and search dearly for a way to sue them.
I don’t love the walled garden iOS represents, I merely live with it in exchange for great hardware and UX. If the bargain changes to be more restrictive, I would turn against it in a heartbeat.
Thinking about that, is no surprise Apple is striking out early to make web apps useless. If they wait too long, they will become entrenched, and people will feel like they have lost something if access is restricted. Apple really wants to jealously protect its control, and more importantly ability to take 30% tax of every transaction that they can perceive.
> "...But deleting all local storage (including Indexed DB, etc.) after 7 days..."
From the Apple announcement:
> Now ITP [Intelligent Tracking Prevention] has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site. ...
https://webkit.org/blog/10218/full-third-party-cookie-blocki...
Do you mean that you deploy a 'native' app that's really just a wrapper around a web view that would also be just Safari? Same policy applies, but now, you have the option, in native code, to siphon off data and put it into Real Storage.