Stalling installing

# Stalling installing Source: [https://adactio.com/journal/22757](https://adactio.com/journal/22757) I’m an invited expert at the World Wide Web Consortium\. That sounds impressive, but it isn’t\. Anyone can become an invited expert\. The fact that I am now one proves it\. You apply to be an invited expert and once that application is approved, you’re in\. So you too could and probably should be an invited expert to a working group at the W3C\. I was strongly encouraged to become an invited expert in the[web applications working group](https://www.w3.org/groups/wg/webapps/)after[weighing in](https://github.com/w3ctag/design-reviews/issues/1245)on the matter of installable web apps \(or progressive web apps or whatever\)\. Last week I had my first call but it wasn’t with the web apps working group, it was with the[technical architecture group](https://tag.w3.org/), a meta\-group that helps the other groups if there’s a big\-picture sticking point\. There’s a big\-picture sticking point with installing web apps\. While most of the participants \(read: browser makers\) would like to spend their time deciding the details of what API to implement in order to support installable web apps, Webkit is rejecting the very premise of that work\. On last week’s call, Webkit outlined[their position](https://github.com/WebKit/standards-positions/issues/619#issuecomment-4448282291): there shouldn’t be a way for developers to allow users to install the current website\. Leave it to the browser, they say\. Also, is this even something that users want? Looking at the stats, it certainly doesn’t seem like it\. That would be a reasonable position if there were already a usable way to install web apps\. But[there isn’t](https://adactio.com/journal/18252)\. It’s*technically*possible to add a website to your iPhone’s home screen\. In practical terms, it’s a convoluted usability nightmare\. \(It’s hard to avoid veering into conspiracy theory territory and seeing this as some kind of malicious compliance\. Especially when you compare it to how native apps are shoved in your face thanks to “[smart app banners](https://developer.apple.com/documentation/webkit/promoting-apps-with-smart-app-banners)” better known as[dickovers](https://daringfireball.net/2026/05/what_is_a_dickover)\.\) So Webkit’s stance would make total sense if there were a reasonable way for users of Mobile Safari to install web apps already\. But there isn’t\. Last week’s call was quite illuminating\. It showed some incredible cognitive dissonance in the Webkit position\. Let me explain… On the one hand, installing web apps is kind of like bookmarking, they say\. That’s true\. We don’t have an API for bookmarking so why should we have an API for installing web apps? That would be a fair point if the user interface for bookmarking and installing were in any way comparable\. But bookmarking is literally front and centre of the user’s experience of a browser, backed up by decades of convention\. Meanwhile the option to install a web app is buried five levels deep behind a “share” icon\. Also: we’re**not**talking about an API for*installing*web apps\. We’re talking about an API for*initialising*the flow for installing web apps—the very same flow that’s triggered from that buried menu item\. And that flow begins with a prominent option to cancel\. So let’s not have any scaremongering about users somehow being tricked into adding web apps to their home screen\. Which brings me to the other point… Webkit are concerned about allowing installed web apps getting access to more powerful APIs\. They’re quite right not to want that\! A web app launched from the home screen shouldn’t have any special privileges\. If it wants access to say, geolocation, the user needs to grant permision just the same as if the page were in the browser\. Why, oh, why then did Apple[limit push notifications to installed web apps](https://adactio.com/journal/19911)? It’s not like other browsers haven’t managed to implement permission\-based APIs like push notifications\. But apparently limiting notifications to installed web apps was the only way that Apple could think of implementing this API safely\. You see the contradiction, right? On the one hand, Webkit is saying that installing web apps is like bookmarking\. No big deal\. On the other hand, Webkit is saying that installing web apps grants special privileges\. A huge deal\! Which is it? It’s almost as if Webkit aren’t actually participating in good faith but rather have already made up their mind to drag their heels when it comes to any kind of progress on this topic\. Anyway… On last week’s call, I was supposedly representing the interests of developers\. No pressure\! I can’t make any claim to represent all developers, but I like to think I’m fairly representative of a typical developer who’s quite fond of the World Wide Web\. So in my allotted ten minutes of speaking time, I said: - Developers would*love*a way to initiate the installation flow\. The alternative is to[provide browser\-specific instructions](https://thesession.org/app)—always a bad sign\. - If browsers provided a prominent usable way to initiate the installation flow, this wouldn’t be such an urgent need\. - Users should have the option to install web apps just like they have the option to install native apps\.*Technically*both options are available, but*practically*the scales are tipped very, very heavily towards native apps\. - Native apps don’t have the same security model as web apps, allowing them much greater access to user data\. If[security](https://www.w3.org/mission/security/)and[privacy](https://www.w3.org/mission/privacy/)are values that the W3C thinks are important for users, they should do everything in their collective power to help tip the scales back in the direction of web apps\.