• Type:

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

There is a huge opportunity for the creation of private client-side-only PWAs in the world but developers wanting to build such apps are in for an uphill battle against the status quo and now against Apple as well. I’ve just read a post by Aral Balkan entitled Apple just killed Offline Web Apps while purporting to protect your privacy: why that’s A Bad Thing and why you should care that made me realize that the PWAs I was building here might just be dead for iOS users.

Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps. — Source: Progressive web apps (PWAs) | MDN

By now, most people are aware of the amount of surveillance and tracking that their web usage is subject to on a daily basis and how this data can be used in ways that do not match their own personal values. It is my own personal belief that there is a market for PWAs that work without a backend component by storing all data for a given user at the user’s own machine. These unify all the benefits of PWAs as mentioned in the quote from MDN WebDocs above with more privacy as data never leaves your machine.

Apps that protect your privacy

It is very easy to prove that the data never leaves the clients computer as any app claiming this kind of privacy but failing to provide it can be scrutinized by web developers using the browsers own dev tools. If there is no backend, then you can have the usual profiling schemes scrutinizing users data to sell to advertising companies, governments, or even shadier entities. For many apps, there is no reason whatsoever to have a backend running.

Many web developers are turning to Electron in these cases but IMHO this is a waste of resources as the Electron runtime is not shared among the different apps running and there is only so many browser engines your computer can run before it has impact on its performance. With Electron you’re never really sure what the app is doing as it has access to basically anything your user can do. In the Web Platform, there are many more guarantees and checks, it is a safer platform than simply running a third-party binary in your machine. Not that I am against those, there are many use cases where it is quite desirable to do so and these use cases vary from people to people, it is about choice in the end. Client-side PWAs without backends are a good match for privacy and don’t waste resources as they share the browser runtime which is probably already running.

Apps that don’t need to work at Web Scale

There are many reasons why FAANG is FAANG, one of them is because they have the money to work at “Web Scale”. This is one reason why many startups look for VCs instead of bootstrapping, they simply don’t have the money necessary to work on the scale they want to work. If you’re doing a hobby project that is a web app and it becomes viral, you might face a lot of trouble scaling your backend to cope with the demand. On the other hand, apps without backends don’t need to play this game. You can have a normal web server, place it on something like cloudflare, use a service worker and go full offline after the first run. Each of your clients only load the app once and probably from some edge cache. There is no database cluster to scale, no AWS to dial up, it doesn’t really matter if you have a single user or millions.

Of course this depends on the kind of application you’re building, I’m mostly talking about personal usage apps that don’t need to exchange data with other people, but even in cases where some form of communication is desirable, you might opt to use some decentralized protocol such as IPFS, Gun, DAT, etc, and provide a different kind of solution. In other cases, providing a feature to save the data in the background to a shared online drive is more than enough. You might not need a backend at all.

I love RSS and blogs so I’m building my own feed reader. I wanted it to be a PWA so that others could benefit from it, but I wanted to do it without a backend server. I don’t want to know what you’re reading, or how much time you spend on a given blog post, I just want to offer a little feed reader. So far my main challenge is not actually what Apple just did, more about that in a bit, but CORS. God damn, I hate CORS! The application can’t reliably fetch the feeds by initiating the requests on the client-side because a ton of sites don’t serve their feeds with the correct CORS headers. The status quo of the web is that there is a server and a client, and stuff happens at the server. It doesn’t need to be this way. You should be able to have client-side only apps, and they should be able to do what you want them to do, but there is no API to request disabling CORS for a given site because the browser vendors think you’re stupid and would click yes without judgement. By thinking you’re stupid, they crippled a ton of potential for client-side-only PWAs.

Apple in its Full Third-Party Cookie Blocking and More | WebKit blog post announced changes to WebKit that erases all local storage data for a given site if the site is not used for seven days. Basically, you go on a vacation and the data is lost. This means that apps must necessarily keep the data on a server, or they risk losing it all because Apple thinks this equates to privacy.

What it does is cripple not only client-side-only PWAs but all PWAs as a big appeal of such technology is for it to be an offline-first and you can’t really go offline-first if you don’t have offline data anymore. Apple is crippling the Web because all it cares about is their native app store and it doesn’t matter how they spin this shit in terms of privacy and security, all they are doing is hurting the web for profit.

Update

There has been quite a lively discussion about this post both on HN and on a comment thread on another post on Lobste.rs. There are many people finding Apple’s wording on that blog post confusing and I’m among them, but some readers concluded that apparently if you install the PWA to the home screen, then its data is safe which would make this a non-issue. I want to remind everyone that installing to the home screen is not what makes a PWA, it is an optional step. A PWA is still a PWA if the user access it only occasionally by typing the URL on the browser or keeping a bookmark. I access many PWAs on my phone but they are not in my home screen because I like to keep it clean. My browser “new tab” lists them for me, they are still as much a PWA as the ones in your home screen.

Picking a case where this arbitrary deletion doesn’t work and thinking it makes it OK, is failing to understand why I’m upset at this and why I think this is a big issue, which might just be me failing to communicate well. For me this is not about data that can be retrieved from server and cache, which greatly degrades the web experience but is not what I’m focusing on. For me this is about preventing web apps to ever work local-only. I’m coming from the decentralization community and am keen on computing on the client and keeping data on the client. This makes it impossible on Apple’s platforms.

Saying that you should build a native app is not an answer. Native apps need to go through gatekeepers, the web does not. The web is the only mass communication media where we all have publishing access (to some degree at least), native iOS apps are not like this. There is a reason Mozilla can’t ship Firefox with Gecko on iOS and the reason is not because they don’t know how to do it. Apple is doing this in the name of privacy but what it actually does is force developers closer to their app store.

#Apple is hurting the #Web again by delivering a crippling blow to #PWAs. #Apple is hurting the #Web again by delivering a crippling blow to #PWAs.

Read More

Previous Post

CH Show HN: I made a site that aggregates entry-level positions

Next Post

Current estimates about the Covid-19 fatality rate may be too high

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top