A message to Apple from the W3C Technical Architecture Group:
We expect user agents to make installation an obvious affordance to users. Specifically, we expect the install option to clearly name the action, and to be easily reachable from the browser’s UI. An entry inside a menu with an unrelated label (such as Share), or several menu layers deep, does not meet this expectation.
Some good ideas on how browsers could offer the ability to install the current site. Frankly, anything would be better than the current woeful situation!
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 after weighing in 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, 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: 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. 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” better known as dickovers.)
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?
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:
There was a time when you needed to make a native app in order to take advantage of specific technologies. That time has passed.
Now you can do all of these things on the web:
Take a look at the home screen on your phone. Looking at the apps you’ve downloaded from an app store, ask yourself how many of them could’ve been web apps.
Social media apps, airline apps, shopping apps …none of them are using technologies that aren’t widely available on the web.
“But”, you might be thinking, “it feels different having a nice icon on my homescreen that launches a standalone app compared to navigating to a bookmark in my web browser.”
I agree! And you can do that with a web app. All it takes the addition of one manifest file that lists which icons and colours to use.
If that file exists for a website, then once the user adds the website to their homescreen it will behave just like native app.
Try it for yourself. Go to instagram.com in your mobile browser and it to your homescreen (on the iPhone, you get to the “add to home screen” option from the sharing icon—scroll down the list of options to find it).
See how it’s now an icon on your home screen just like all your other apps? Tap that icon to see how it launches just like a native app with no browser chrome around it.
This doesn’t just work on mobile. Desktop browsers like Chrome, Edge, and Safari also allow you to install web apps straight from the browser and into your dock.
About half of the icons in my dock are actually web apps and I honestly can’t tell which is which. Mastodon, Instagram, Google Calendar, Google Docs …I’m sure most of those services are available as downloadable desktop apps, but why would I bother doing that when I get exactly the same experience by adding the sites to my dock?
From a business perspective, it makes so much sense to build a web app (or simply turn your existing website into a web app with the addition of a manifest file). No need for separate iOS or Android developer teams. No need to play the waiting game with updates to your app in the app store—on the web, updates are instant.
You can even use an impressive-sounding marketing term for this approach: progressive web apps:
A Progressive Web App (PWA) is a web app that uses progressive enhancement to provide users with a more reliable experience, uses new capabilities to provide a more integrated experience, and can be installed. And, because it’s a web app, it can reach anyone, anywhere, on any device, all with a single codebase. Once installed, a PWA looks like any other app, specifically:
- It has an icon on the home screen, app launcher, launchpad, or start menu.
- It appears when you search for apps on the device.
- It opens in a standalone window, wholly separated from a browser’s user interface.
- It has access to higher levels of integration with the OS, for example, URL handling or title bar customization.
- It works offline.
But there’s still one thing that native apps do better than the web. If you want to be able to monitor and track users to an invasive degree, the web can’t compete with the capabilities of native apps. That’s why you’ll see so many websites on your mobile device that implore to install their app from the app store.
If that’s not a priority for you, then you can differentiate yourself from your competitors by offering your users a progressive web app. Instead of having links to Apple and Google’s app stores, you can link to a page on your own site with installation instructions.
I can guarantee you that users won’t be able to tell the difference between a native app they installed from an app store and a web app they’ve added to their home screen.
Rich suggests another reason why the UX of websites on mobile is so shit these days:
The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.
A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?
Back in June I documented a bug on macOS in how Spaces (or whatever they call they’re desktop management thingy now) works with websites added to the dock.
I’m happy to report that after upgrading to Sequoia, the latest version of macOS, the bug has been fixed! Excellent!
Not only that, but there’s another really great little improvement…
Let’s say you’ve installed a website like The Session by adding it to the dock. Now let’s say you get an email in Apple Mail that includes a link to something on The Session. It used to be that clicking on that link would open it in your default web browser. But now clicking on that link opens it in the installed web app!
It’s a lovely little enhancement that makes the installed website truly feel like a native app.
Websites in the dock also support the badging API, which is really nice!
I wonder if there’s much point using wrappers like Electron any more? I feel like they were mostly aiming to get that parity with native apps in having a standalone application launched from the dock.
Now all you need is a website.
The biggest issue remains discovery. Unless you already know that it’s possible to add a website to the dock, you’re unlikely to find out about it. That’s why I’ve got a page with installation instructions on The Session.
Still, the discovery possibilities on Apples’s desktop devices are waaaaay better than on Apple’s mobile devices.
Apple are doing such great work on their desktop operating system to make websites first-class citizens. Meanwhile, they’re doing less than nothing on their mobile operating system. For a while there, they literally planned to break all websites added to the homescreen. Fortunately they were forced to back down.
But it’s still so sad to see how Apple are doing everything in their power to prevent people from finding out that you can add websites to your homescreen—despite (or perhaps because of) the fact that push notifications on iOS only work if the website has been added to the home screen!
So while I’m really happy to see the great work being done on installing websites for desktop computers, I’m remain disgusted by what’s happening on mobile:
At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation.
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!
My bug report on Apple’s websites-in-the-dock feature on desktop has me thinking about how starkly different it is on mobile.
On iOS if you want to add a website to your home screen, good luck. The option is buried within the “share” menu.
First off, it makes no sense that adding something to your homescreen counts as sharing. Secondly, how is anybody supposed to know that unless they’re explicitly told.
It’s a similar situation on Android. In theory you can prompt the user to install a progressive web app using the botched BeforeInstallPromptEvent. In practice it’s a mess. What it actually does is defer the installation prompt so you can offer it a more suitable time. But it only works if the browser was going to offer an installation prompt anyway.
When does Chrome on Android decide to offer the installation prompt? It’s a mix of required criteria—a web app manifest, some icons—and an algorithmic spell determined by the user’s engagement.
Other browser makers don’t agree with this arbitrary set of criteria. They quite rightly say that a user should be able to add any website to their home screen if they want to.
What we really need is an installation API: a way to programmatically invoke the add-to-homescreen flow.
Now, I know what you’re going to say. The security and UX implications would be dire. But this should obviously be like geolocation or notifications, only available in secure contexts and gated by user interaction.
Think of it like adding something to the clipboard: it’s something the user can do manually, but the API offers a way to do it programmatically without opening it up to abuse.
(I’d really love it if this API also had a declarative equivalent, much like I want button type="share" for the Web Share API. How about button type="install"?)
People expect this to already exist.
The beforeinstallprompt flow is an absolute mess. Users deserve better.
Hallelujah! Apple have backed down on their petulant plan to sabatoge homescreen apps.
I’m very grateful to the Open Web Advocacy group for standing up to this bullying.
This is exactly what it looks like: a single-fingered salute to the web and web developers.
Read Alex’s thorough explanation of the current situation and then sign this open letter.
Cupertino’s not just trying to vandalise PWAs and critical re-engagement features for Safari; it’s working to prevent any browser from ever offering them on iOS. If Apple succeeds in the next two weeks, it will cement a future in which the mobile web will never be permitted to grow beyond marketing pages for native apps.
Also, remember this and don’t fall for it:
Apple apparently hopes it can convince users to blame regulators for its own choices.
When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.
The European Union’s Digital Markets Act is being enforced and Apple aren’t happy about it.
Most of the discussion around this topic has centred on the requirement for Apple to provision alternative app stores. I don’t really care about that because I don’t really care about native apps. With one exception: I care about web browsers.
That’s the other part of the DMA that’s being enforced: Apple finally have to allow alternative browsing engines. Hallelujah!
Instead of graciously acknowledging that this is what’s best for users, Apple are throwing a tantrum.
First of all, they’re going to ringfence any compliance to users in the European Union. Expect some very interesting edge cases to emerge in a world where people don’t spent their entire lives in one country.
Secondly, Apple keep insisting that this will be very, very bad for security. You can read Apple’s announcement on being forced to comply but as you do you so, I’d like you to remember one thing: every nightmare scenario they describe for the security of users in the EU is exactly what currently happens on Macs everywhere in the world.
This includes risks from installing software from unknown developers that are not subject to the Apple Developer Program requirements, installing software that compromises system integrity with malware or other malicious code, the distribution of pirated software, exposure to illicit, objectionable, and harmful content due to lower content and moderation standards, and increased risks of scams, fraud, and abuse.
Users of macOS everywhere are currently exposed to all the risks that will supposedly overwhelm iOS users in the European Union. Weirdly, the sky hasn’t fallen.
It’s the same with web browsers. I just got a new Mac. It came with one browser pre-installed: Safari. It’s a good browser. But I also have the option of installing another browser, like Firefox (which I’ve done). A lot of people just use Safari. That’s good. That’s choice. Everyone wins.
Now Apple need to provide parity on iOS, at least for users in the EU. Again, Apple are decribing this coming scenario as an absolute security nightmare. But again, the conditions they’re describing are what already exist on macOS.
All Apple is being asked to do is offer than the same level of choice on mobile that everyone already enjoys on their computers. Rather than comply reasonably, Apple have found a way to throw their toys out of the pram.
As of the next update to iOS, users in the EU will no longer have homescreen apps. Those web apps will now launch in a browser window. Presumably they’ll also lose the ability to send push notifications: being a homescreen app was a prerequisite for that functionality.
This is a huge regression that only serves to harm and confuse users.
I have a website about traditional Irish music. Guess where a significant amount of the audience is based? That’s right: Ireland. In the European Union.
There is no native app for The Session, but you can install it on your phone nonetheless. Lots of people have done that. After a while they forget that they didn’t install it from an app store: it behaves just like any other app on their homescreen.
That’s all about to change. I’m going to get a lot of emails from confused users wondering why their app is broken, now opening in a regular browser window. And I won’t be able to do anything about it, other than to tell them to take it up with Apple.
Presumably Apple is hoping that users will direct their anger at the EU commission instead. They’re doing their best to claim that they’re being forced to make this change. That’s completely untrue. A lie:
This is emphatically not required by the EU’s Digital Markets Act (DMA). It’s a circumvention of both the spirit and the letter of the Act, and if the EU allows it, then the DMA will have failed in its aim to allow fair and effective browser and web app competition.
Throughout all their communications on this topic, Apple are sticking to their abuser logic:
Look what you made me do!
This is going to hurt me more than it hurts you.
Apple’s petulant policy of malicious compliance is extremely maddening. What they’re about to do to users in the EU is just nasty.
This is a very dark time for the web.
I feel bad for the Safari team. They’ve been working really hard recently to make Safari a very competitive browser with great standards support with a quicker release cycle than we’ve seen before. Then it all gets completely torpedoed at the level of the operating system.
I really hope that Apple won’t get away with their plan to burn down web apps on iOS in the EU. But hope isn’t enough. We need to tell the EU commission how much damage this will do.
If you’ve ever built a web app, then your users will suffer. Remember, it’s a world wide web, including the European Union.
Create a PDF with the following information:
The submission can be as short or long as you want. Send it to contactus@open-web-advocacy.org, ideally before Monday, February 19th.
I know that’s a lot to ask of you on your weekend, but this really matters for the future of the web.
At the very least, I encourage to get involved with the great work being done by the Open Web Advocacy group. They’re also on Discord.
Please don’t let Apple bully an entire continent of users.
I don’t like to assume the worst and assign vindictitive motives to people, but what Apple is doing here is hard to read as anything other than petulant and nasty …and really, really bad for users.
If you’ve ever made a progressive web app, please fill in this survey.
Web Push on iOS is nearing its one year anniversary. It’s still mostly useless.
Sad, but true. And here’s why:
On iOS, for a website to be able to ask the user to grant the push notification permission, it needs to be installed to the home screen.
No other browser on any of the other platforms requires you to install a website for it to be able to send push notifications.
Apple is within their rights to withhold Web Push to installed apps. One could argue it’s not even an unreasonable policy - if Apple made installing a web app at least moderately straightforward. As it is, they have buried it and hidden important functionality behind it.
I really, really hope that the Safari team are reading this.
Oh no! My claim has been refuted by a rigourous scientific study of …checks notes… ten people.
Be right back: just need to chat with eleven people.
An entire generation of apps-that-should-have-been web pages has sprung up, often shoehorned into supposedly cross-platform frameworks that create a subpar user experience sludge. Nowhere is this more true than for media — how many apps from newspapers or magazines have you installed, solely for a very specific purpose like receiving breaking news alerts? How many of those apps are just wrappers around web views? How many of those apps should have been web pages?
Instead of doing what the competing browsers are doing (and learning from years of experience of handling Web Push), Apple decided to reinvent a wheel here. What they’ve turned up with looks a lot more like a square.
Push notifications are finally arriving on iOS—hallelujah! Like I said last year, this is my number one wish for the iPhone, though not because I personally ever plan to use the feature:
When I’m evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn’t support them—even though desktop Safari does—I’m somewhat stumped. There’s no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.
With push notifications in mobile Safari, the arguments for making proprietary apps get weaker. That’s good.
The announcement post is a bit weird though. It never uses the phrase “progressive web apps”, even though clearly the entire article is all about progressive web apps. I don’t know if this down to Not-Invented-Here syndrome by the Apple/Webkit team, or because of genuine legal concerns around using the phrase.
Instead, there are repeated references to “Home Screen apps”. This distinction makes some sense though. In order to use web push on iOS, your website needs to be added to the home screen.
I think that would be fair enough, if it weren’t for the fact that adding a website to the home screen remains such a hidden feature that even power users would be forgiven for not knowing about it. I described the steps here:
- Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
- A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
- Now you must find “add to home screen” in the list
- Copy
- Add to Reading List
- Add Bookmark
- Add to Favourites
- Find on Page
- Add to Home Screen
- Markup
As long as this remains the case, we can expect usage of web push on iOS to be vanishingly low. Hardly anyone is going to add a website to their home screen when their web browser makes it so hard.
If you’d like to people to install your progressive web app, you’ll almost certainly need to prompt people to do so. Here’s the page I made on thesession.org with instructions on how to add to home screen. I link to it from the home page of the site.
I wish that pages like that weren’t necessary. It’s not the best user experience. But as long as mobile Safari continues to bury the home screen option, we don’t have much choice but to tackle this ourselves.
I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.
Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That’s it. No need to download an app.
That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.
Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.
Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.
At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?
Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.
That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.
On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.
When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.
I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.
I’ve linked to the page with the installation instructions from the site’s “help” page and the home page.
Handy tip: when you’re adding a start_url value to your web app manifest, it’s common to include a query string like this:
start_url: "/?homescreen"
I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.
If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.
Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲
It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.
(I’m not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)
If you download Safari Technology Preview you can test drive features that are on their way in Safari 15. One of those features, announced at Apple’s World Wide Developer Conference, is coloured browser chrome via support for the meta value of “theme-color.” Chrome on Android has supported this for a while but I believe Safari is the first desktop browser to add support. They’ve also added support for the media attribute on that meta element to handle “prefers-color-scheme.”
This is all very welcome, although it does remind me a bit of when Internet Explorer came out with the ability to make coloured scrollbars. I mean, they’re nice features’n’all, but maybe not the most pressing? Safari is still refusing to acknowledge progressive web apps.
That’s not quite true. In her WWDC video Jen demonstrates how you can add a progressive web app like Resilient Web Design to your home screen. I’m chuffed that my little web book made an appearance, but when you see how you add a site to your home screen in iOS, it’s somewhat depressing.
The steps to add a website to your home screen are:
It reminds of this exchange in The Hitchhiker’s Guide To The Galaxy:
“You hadn’t exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.”
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a torch.”
“Ah, well the lights had probably gone.”
“So had the stairs.”
“But look you found the notice didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of The Leopard.’”
Safari’s current “support” for adding progressive web apps to the home screen feels like the minimum possible …just enough to use it as a legal argument if you happen to be litigated against for having a monopoly on app distribution. “Hey, you can always make a web app!” It’s true in theory. In practice it’s …suboptimal, to put it mildly.
Still, those coloured tab bars are very nice.
It’s a little bit weird that this stylistic information is handled by HTML rather than CSS. It’s similar to the meta viewport value in that sense. I always that the plan was to migrate that to CSS at some point, but here we are a decade later and it’s still very much part of our boilerplate markup.
Some people have remarked that the coloured browser chrome can make the URL bar look like part of the site so people might expect it to operate like a site-specific search.
I also wonder if it might blur “the line of death”; that point in the UI where the browser chrome ends and the website begins. Does the unified colour make it easier to spoof browser UI?
Probably not. You can already kind of spoof browser UI by using the right shade of grey. Although the removal any kind of actual line in Safari does give me pause for thought.
I tend not to think of security implications like this by default. My first thought tends to be more about how I can use the feature. It’s only after a while that I think about how bad actors might abuse the same feature. I should probably try to narrow the gap between those thoughts.