Hacker News new | past | comments | ask | show | jobs | submit login

I don't understand what the problem is.

I can easily go to the settings area and delete my entire browser cache (Remove All Website Data), in fact if you are running low of space it even tells you to do it.

Why are people assuming things stored on a browser are a good place to store things. Nothing stored on a browser should be assumed to be forever.






If you read the article, that's the issue the author was talking about: it's basically impossible to make an app that can store its data locally, instead of on some web server.

All apps that you download from App Store can live offline, where they're usable without Internet or trusting some faraway web server.

You can't make a web app that can do that, and to some people it smells like Apple trying to force developers to release through App Store.


I don't really understand this. If you want to make something local, make an app and distribute through the app store, that's what it is for. A web app on the other hand is connected by definition, no?

Apple forcing local apps to distribute through the app store is a feature.


> A web app on the other hand is connected by definition, no?

No, not in the era of "progressive web apps", which is really just a little bit of branding around interconnected APIs. The Cache API in particular means that a webapp can be downloaded and made available offline on a permanent basis. Unless it isn't actually permanent at all, which is what Apple are doing here.

The web and the App Store are just delivery mechanisms for code with different trade-offs built into them. Apple have added an extra trade-off on the web side in the name of privacy.


Having worked on a cross platform application that defined the UI via HTML I'm still kinda confused about this use case - it's super trivial to wrap a set of HTML + JS in an app that's essentially just a full screen webkit/whatever window and distribute this.

The advantage of PWAs then seems to be the ability to dodge the app store certification which, while onerous, is not a bad thing for your clients.


> [...] is not a bad thing for your clients

Except when you have to pass some of the 30% Apple fee on to your clients.


This is equal to saying “I’m ok with Apple having a censorship monopoly of what an iPhone can run”. I don’t think the majority of people here would agree with that. I also don’t think users buying a device that is supposed to support web apps would be happy to find out that in fact it doesn’t. I’m one of those very unhappy users.

Personally I would never expect a web app to be available offline on a permanent basis.

That's just a failure of your imagination, though. The world was not always as it is today, and it is not bound to be so in the future.

Okay?

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

Okay?

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


To an end user there’s an icon on their screen, they tap it, the app opens. It didn’t matter if they downloaded from the AppStore or from a website. This is no longer the case which is why the OP is upset.

Pretty sure it is still the case if they have connectivity...

Let's say you use an app that allows you to add Todos. You've added 30 Todos. No internet needed, it's always just worked. You go on vacation for 10 days. You get back, you open your app. No Todos...all gone. Very simple use case that is now broken.

Yes, you as the user could wipe those out. But now Apple is doing it just because you didn't use it in 7 days. And the user will not blame Apple, they won't even know Apple did that. They will blame the app developer, who in the interest of privacy didn't want to push your personal Todos to a database online.

Again, just a contrived example, please don't go down the road of why a server should have been used. Let's stick to the use case described.


I actually have an old phone that I used as a remote-control for my home-threater PC. No connectivity needed, but the phone did everything I needed. Move the mouse, act as a keyboard, and mostly raise volume / change channel.

Phones are computers. Even if you remote all connectivity to the outside world, they still function as well as any PC from the early 90s (or earlier). A huge amount of compute power, tons of storage, etc. etc.


Its not, at least not based on how the OG article is written. If you open your bank app it automatically tries to log you in if you saved your credentials in the past. This seems to say that if you don't use the app for a week it'll wipe that out. No one expects that.

That's not how I read it. Odds are my bank isn't using local storage for that.

That's the same era as the "year of the Linux" desktop. I keep hearing "PWAs will win" for ten years now. Some people just want to use ill-fitted web tech everywhere, because that's all they know.

No, it's a grab for money. Releasing an iOS app requires Apple hardware, X-code, and an Apple developer license which is $100/yr.

Where as developing a PWA can be done on any hardware, and would be natively cross-platform. An offline PWA does not require an active connection, and in fact is the one of the reasons behind the idea of developing a PWA instead of a general webapp or website.

All other browsers allow the use of local storage to optimize and enhance your experience by allowing things like pre-loading data or storing your preferences. This disappears with the decision Apple made to clear storage.


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

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

Exactly. The app store's gross revenue was $54 billion last year. [1] Apple has a very strong incentive to make sure the only good way to deliver apps on iOS is the app store.

[1] https://www.statista.com/statistics/296226/annual-apple-app-...


Interesting numbers. I see, "gross revenue" means:

> In the last reported year, customers spent an estimated 54.2 billion U.S. dollars on on in-app purchases, subscriptions, and premium apps in the Apple App store.

So, roughly 30% cut goes to Apple - which is around 16 billion; and developers got the rest, around 38 billion.

With PWAs, 100% goes to developers. As you pointed out, that's a threat and motivation for Apple to continue racheting up their closed ecosystem, and keep PWAs crippled on Apple devices.


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

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

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


(Looks at home screen) Slack, Jira, LastPass, and Netflix. All Native apps that are free via the App Store, and all with the subscription model that I pay for. And for most of those I can’t even buy the subscription from inside of the native app, so Apple gets no money from these

And for most of those I can’t even buy the subscription from inside of the native app, so Apple gets no money from these

This is where things get pretty shady with Apple's terms for native apps and the App Store. Take a look at Spotify's experience for a different version of the story.


Can you give a few examples of paid-for PWAs? Sure there are websites that are paid-for, but I've never seen a paid-for PWA.

Financial Times[0] is a PWA and with a paid service option.

[0]: http://app.ft.com/


I'm posting pseudonymously here, so please forgive me for not citing personal examples, but the normal web apps for accessing quite a few popular services are now PWAs. Spotify famously started looking into using a PWA after some issues with Apple regarding the cut taken with a native app. Uber is another well-known example.

Yes, and they shouldn’t be taking a cut. Their services initiatives are bad for them and the users of said services. But as someone who did two tours in their services arm, it is overwhelmingly likely that the reason that WebKit is making these changes is their stated reason of making Safari more resilient to the attacks on their users vectored in by web badness.

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

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


I think you missed the "requires Apple hardware". I know that rich Americans think everyone has Macbooks, but that is not the case.

They care about they revenue they get by making people buy the hardware that gives them access to the developer program.

Then why not make it free?

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

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

A feature for who?

Not for users - now there's one less avenue for developers to get them something they want.

Not for developers - now they have to jump through additional hoops to make something that works cross platform.

Who exactly does this benefit?


Users want to be able to log in and see their data from any device. If the whole idea is that there is no server that the data is stored on, then you can't have a sync function, can you?

Do any of you have an example of a good offline-only PWA that will be affected by this?


The whole point is that those PWAs probably never got built in the first place because the foundations were always shaky at best. It's a chilling effect.

But if you look at native apps, especially ones I use on desktop OSes, they're dominated (at least in my usage) by offline-first or offline-only apps---and for me, this is a feature, not a bug. This doesn't have to mean they don't have sync, by the way, it just means that's separate from the main functionality of the app.

A perfect example of this is Dropbox: it syncs to your local disk by default. It's easy to forget how valuable this is until you go camping (or similar) and suddenly you realize you forgot to star that one directory you care about. Now your mobile phone is useless, but your laptop works no problem. And due to this being factored out into a separate app, all my files now work regardless of file type (I don't need separate offline support in every app I use, since that's the default).


The whole point is that you don't need to download a big payload just because you haven't used it recently.

There are two ideas that go together well:

* The app can work offline

* The app doesn't need a server to function

Neither of those prevent a sync function from existing.

Right now, apps can do both of those. Why don' we want PWA's to be able to do the same? Why do I have to go through Apple's walled garden in order to so? Especially when said alternative is in a sandbox?


It's no less of an issue for an online-based PWA. Where do you store login credentials or session tokens? In local storage. What happens to them when Apple decides to arbitrarily throw it away? The user has to log in again and again.

This sounds like a seriously poorly thought out idea. Want to clear tracking data from random websites I've been to? That's great. But you don't mess with the data stored by apps I have specifically _chosen_ to install on _my_ device.


But only if they don’t interact with it for a week. I wouldn’t be surprised if a web app I hadn’t used for a week required me to login.

There are many apps on my phone that I only use every once in a while, yet every single one of them remembers me. No matter how long I've been gone. Technology is amazing!

Where is Apple's famous UX here? What legitimate argument is there for clearing data of an app the user has added to their home screen?


And most native apps crash one a week, we should therefore automatically crash every app once a week.

Just because current apps are buggy doesn't mean we should enforce those bugs at a platform level.


I wouldn't be surprised but I would definitely be upset.

It means you constantly have to re-login on a PWA (e.g. Twitters web client PWA).

Constantly being weekly at most frequent in this case.

I roll my eyes every time robinhood makes me login again after an app update... though it hasn't happened in a while, so maybe they fixed that bug, but it was annoying when it's an unexpected hurdle that doesn't follow what other apps are doing.

Games with your personal high scores. Is the one that would affect me

Plus a local note-taking app I created a while ago


> If you want to make something local, make an app and distribute through the app store, that's what it is for.

Have you ever gone through the app review process? It can be frustratingly capricious, which makes it very expensive. We've had features in our app for years, displayed in plain sight, and then all of a sudden they decide to block an update because of these utterly innocuous features. No rhyme or reason, and now we've got to spend dev time fixing a "problem" that never was a problem before. And we have to delay our entire update because of it.

PWAs offer a way around that uncertainty and added cost. There's also the cost of a developer license, and the Apple hardware you have to buy to run XCode (and probably iOS devices too, so you can test IRL).


Apple's app store is a walled garden. The web isn't a walled garden. TFA wants to be able to operate outside the walled garden.

EDIT: Also, it's probably cheaper to develop one PWA than a PWA + N native apps, even if N=2. Probably lots cheaper. Now, perhaps there's a way to build a native app that is just a wrapper around WebKit/Safari and a PWA, but you'd still be subject to Apple's walled garden. For example, think of Gab or some such website whose apps have been banned by the various app stores...


So you can think of absolutely no situation where a user would access a web app, and might want to store state info locally?

I can personally think of cases (not that PWAs have ever been anything but fragile when it comes to locally stored data), but as a user, the occasional clearing of super cookies is a bigger boon.

I don't disagree that local data for PWAs has always been fragile. I wished browsers were taking steps to make it less fragile, as opposed to more fragile. It would allow certain use cases to become valid for PWAs, thereby circumventing the need to create a 10mb native app for something that can be deployed much more easily and quickly with 30kb of Javascript.

Respectfully, I haven't visited an online SPA with under 100kb of Javascript in a very long time. Anytime I care to look, they are almost always in the 5mb range.

So, an offline app's size, when compared to just browsing the web, isn't a compelling difference (especially since it's downloaded maybe once a month or so).


> A web app on the other hand is connected by definition, no?

No, it just has to run in a browser.


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

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

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

I mean, if you give the app access to your filesystem (which a lot of non-tech users would, almost without thinking), it can potentially access/modify/delete your files and folders. With PWAs, that's not really a possibility.

Stock iOS doesn’t allow apps to directly access data from other apps afaik

Has to come from somewhere. A pwa might have to come via http (I'm not sure) - but html+js+css can come from the (from a) filesystem too. Like an USB-c memory stick.

Or from an extracted archive (much like a native app).


> A pwa might have to come via http

They can't, PWAs can only be served over https


People keep wishing for a loophole. There isn’t one they won’t close sooner or later.

At one point, Apple was denying some app store reviews because they said they should be distributed through PWAs instead. If this is supposed to be a "feature", it seems like some product manager has their head up their ass.

Also, the entire point of PWAs is that they are supposed to have feature parity with local apps, but delivered via the browser. This change is obviously counter to that goal.


"Apple forcing local apps to distribute through the app store is a feature."

Forcing companies to give Apple 30% is not a feature.

If companies feel they can deliver a net experience in webapp that's better than an app, then so be it, it's their choice.

App makers are smart enough to know what makes sense for them.


You should research the original plan for "apps" on the iOS platform. There was no "native app" story originally, and Javascript-based applications were expected to be the only 3rd party platform on the OS.

As should you. It’s not that an app ecosystem was never planned, it’s that it was not an early priority. Remember they were literally defining everything at the beginning - OS, UX, APIs, core features, hardware, first party apps, market positioning, etc etc. Needs of third party developers weren’t nearly as important as nailing the basics and ensuring a risky project was a success. The html5 app bit was a way to test the waters for developer interest and demand but very much an interim solution.

How do you square that against all the reported accounts (including the Isaacson biography) of Steve Jobs saying that he was opposed to third-party native applications on the platform?

Yes, they changed direction in 2008. That's just it, though. They changed direction.


Jobs’ hot takes aren’t the end-all when it comes to product intent at Apple. He was basically an embodiment of strong opinions weakly held. His superpower was focusing teams on what the right set of features would be to create a product that made sense to the market, and ignoring everything else. The phone / iPod / internet communicator trifecta was example of this - nothing but nailing those three mattered at launch, and any effort elsewhere was wasteful. Without that kind of leadership, eng teams will often dither efforts over many things that don’t matter to success.

The history of Apple is filled with examples of this dynamic. iPhone was a group effort among many talented and influential people and I doubt Forstall and others driving software had same opinion on third party apps. They just didn’t pick that battle before it made sense to. Every other computing platform at the time (including Windows Mobile, Palm, and BlackBerry) supported third party apps, it’s not like the use case was novel or difficult to see, and the webs limitations were considerable. Adding apps was a default path temporarily set aside.


That was not the plan, that was the stopgap. Apple (and even more the networks) were very scared that native apps would have unregulated access to the radio, and would mess with the cell networks. Web apps were the quick-and-dirty way of putting third party apps into a sandbox while Apple worked on APIs that would enforce that sort of sandbox for native apps (what they have now).

It doesn't have to be that way though, that's the point of PWAs. A way to use web technologies for local applications.

If you read the update from webkit.org, you'll see that it's still quite possible to store data locally.

Link: https://webkit.org/blog/10218/full-third-party-cookie-blocki...

Relevant quote (emphasis mine):

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

If a website hasn't been used for 7 days, I'm happy for its data to disappear and save space on my device.


If a website hasn't been used for 7 days, I'm happy for its data to disappear and save space on my device.

You might be, but maybe not everyone is. I've worked on apps based around multimedia content where downloading in advance to watch or listen later was a big deal, because a typical user also travels a lot and might well be going away for longer than a week. Even if they can get the same data again next time they're online, it might still be much slower and more expensive for them to do that on an international data plan instead of back home.


Then wouldn't it be appropriate to offer a native app to offer that functionality? A web browser in 2020 is a place to run vast swathes of untrusted code safely; it is not a digital workstation platform, that is the job of the OS. If what I am downloading from you is important enough that I want to have it even offline, then I trust you enough to install your native app.

A web browser in 2020 is a place to run vast swathes of untrusted code safely; it is not a digital workstation platform, that is the job of the OS.

I'm not sure how much that assumption really holds any more, nor why it should necessarily continue to do so even if it has so far. Technology evolves, and so does how we use it. In the case of the web, and web apps in particular, they have evolved to satisfy a need for convenience in software distribution that many traditional desktop OSes had hopelessly neglected for a very long time and where the developer experience for native mobile apps is less than ideal.

I appreciate your comment about the trust issue, but the bottom line is that these technologies do serve a useful purpose for some people -- I have the customer feedback at my own businesses to make that clear -- and the experience web developers can offer on Android with PWAs will now be significantly better than what they can offer on iOS.


I believe this entire statement is wrong in 2020. There are literally OSes now that are just browsers.

The fact that that is possible does not change the role of the web browser in the modern computing experience. If you want to build an entire VM that runs in Electron, be my guest, but that's orthogonal to the issue of how Safari should handle storage by default.

The fact that that is possible does not change the role of the web browser in the modern computing experience.

But why shouldn't new possibilities change the modern computing experience or the role of browsers within it? Millions of users are benefitting from new capabilities of modern browsers, even if they don't know the details any more than they know what goes into any other software they use. Why is local storage of data, or the idea of a PWA more generally, special in this respect?


That's been true for years, and yet the operating systems that aren't just browsers seem to be getting along just fine.

7 days is actually a really short period. There are lots of apps and websites that I only open on my phone every now and then. I would never use them if I had to log in almost every time.

> it's basically impossible to make an app that can store its data locally, instead of on some web server.

No, that is trivial to do: just make an actual damn application.

What the author is complaining about is that it’s impossible to make a text document that pretends to be an application that stores data in ways they were never intended to be stored.


I'm sorry but I find this argument utterly tedious.

A Swift file is no less a "text document" than a JavaScript file is. There are APIs available in the browser to store data offline, so I have no idea what "in ways they were never intended to be stored" means here.

A webapp is "an actual damn application". Can we just dispense with the repetitive arguments about this every time anyone so much as mentions adding interactivity to a web page?


"just write an iOS app" versus "my web application can be used on Apple devices" is a bit much, don't you think?

No, that is trivial to do: just make an actual damn application.

So trivial that all it needs is learning a completely new skill set and tools, signing up for a gated distribution mechanism that can kill your application on a whim if you violate any of the rules over which you have no control, and then giving a huge cut of your revenues to the rent-seeking platform owner?

The web has been more than just text documents since around the turn of the millennium. It's probably about time we stopped ignoring 20 years of very popular evolution and pretending that what might have been "intended" before a lot of people reading this comment were born should still guide what we build today.


> What the author is complaining about is that it’s impossible to make a text document that pretends to be an application that stores data in ways they were never intended to be stored.

You must've been not following things. The web platform is an application platform and has developed to that end, for many years.

Progressive Web Apps are applications based on standard Web APIs that are designed with the intent to enable offline-capable applications with persistent offline storage of significant amounts of data.


> The web platform is an application platform and has developed to that end, for many years.

No it’s not. Using it like that is a lasagna of dirty hacks. The web is for structured text with hyperlinks, everything else is bullshit that doesn’t belong on the web.


> No it’s not. Using it like that is a lasagna of dirty hacks.

First it's a bunch of dirty hacks. Then it's an informal convention. Then it's a standard. Lots of technology evolved that way.

All the stakeholders driving the web standards forward are focusing on making it a more powerful application platform.

> The web is for structured text with hyperlinks, everything else is bullshit that doesn’t belong on the web.

That's your personal opinion on what the web platform should be, not what it is. Of course it's a crappy platform in many respects. Of course a lot of people don't like the way it goes. It doesn't matter.


Who are the “some people”?

Are any of them outside of chrome’s WebWorker team, or the community of devs that were suckered into a model that really has never gained traction for iOS?

I’m sort of sympathetic to the devs who bought in to the solution, but this looks an awful lot like a pr pressure campaign that is unhappy with how this affects googles disintermediation goals.


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

I can delete data from my hard drive, why are people assuming things stored on a computer is a good place to store things. Nothing stored on a computer should assumed to be forever

If you are distribting a PWA through e.g. electron the user does not have (easily) the means to delete the cache. Web app is a misnomer in that case, they are just applications running inside a somewhat hidden browser.

The problem is, that it rarely happens under normal circumstances. So you might build a logic which synchronizes your data to the server but rarely has to download it as most of the time it still has a relatively current snapshot. And the few times you have to download everything, it is ok for the user to wait a while.

But if you have to wait every time your last interaction is more than 7 days ago, the whole experience will change. And supporting a reliable offline experience will be very hard to build.


There's a big difference between a user choosing to clear their data and a browser vendor deciding to clear a user's data.

That's like asking why people store files on disks when they could store everything in the cloud.

I also don't understand the alarm.

There is no hard limit on how long things will be stored. Data in localStorage might still be stored for weeks/months/years, as before.

The only limit is on how long things will be stored if the user does not interact with the site/PWA.

If you are a website, not a natively-installed app, that I haven't "used" in a first-party sense for 7 days or more, I don't think your data belongs on my device.

Storage space can be limited, and any app I haven't used in 7 days should be happy to re-fetch my data from a server or convince me to install their native app.

To act like this is some nefarious plan by Apple to get people to build native apps instead of PWAs is absurd. If a PWA was written properly in the first place, this change will have basically 0 impact on it.


It is certainly a plan to further relegate PWAs because they directly challenge the monetization strategy of apple. Its an area where their interests do not align with user interests. A "properly written" PWA may offer things like not re-fetching data from the internet when you already have it locally, and / or not forcing you to create an account just to save some basic data (ex: A recipe app, a jobs search app, etc). Consider for example, saving a job search website as an app, and being able to search and save jobs without having to make an account. An account could be offered if you want cross device syncing, but is not required just to save jobs. Which is great because some users prefer to remain anonymous, and PWA's open the door to that type of thing (as a singular example).

This move is _an_ example of Apple's (understandable) hostility towards PWA's, but you must understand the context here: There is a threshold beyond which PWA's become a generally acceptable strategy, and the quality and diversity rise over time. Apple is preventing that with this move (and others). That's why people are upset. Moreover, the outcome of this will be more "native" apps that are actually just wrappers around web apps, that exist purely because some basic functionality is being actively blocked by Apple.


> Consider for example, saving a job search website as an app, and being able to search and save jobs without having to make an account. An account could be offered if you want cross device syncing, but is not required just to save jobs. Which is great because some users prefer to remain anonymous, and PWA's open the door to that type of thing (as a singular example).

Consider the use-cased of this example. If I am actively job-searching, I will probably be using the site at least once per week, and the data will be saved throughout the process. When I stop using the site, I want that data to disappear for my own privacy/security; and if users want to save the data indefinitely without signing up for an account, then offering an export (e.g. CSV) seems like a reasonable way to address that.

Furthermore, non-Apple user agents may retain data as long as they like, and PWA's (as well as web trackers) are free to utilize that. It's not like this move implements any additional vendor lock-in; people who don't like it will switch to non-Apple platforms.

> Moreover, the outcome of this will be more "native" apps that are actually just wrappers around web apps, that exist purely because some basic functionality is being actively blocked by Apple.

This doesn't seem problematic. It's great if you can reuse some code between your web and native apps. Obviously truly-native UIs will be more efficient in many cases, but perfect needn't be the enemy of good.


Aren't there websites you use less than once a week?

If one of those is using a JWT for auth in localStorage (something which is extremely common) you'd need to login every time you visit such site.


Yes, and that's fine with me. Being on an iPhone, I use the built-in cloud-backed password manager which makes generating and entering credentials near-effortless. Furthermore, by not leaving long-lived tokens in my browser's storage, I'm less vulnerable to exploits that may exfiltrate that data.



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

Search: