In an earlier era, startups could build on the web and, if one browser didn’t provide the features they needed, they could just recommend that their users try a better one. But that’s not possible on iOS.
I’m extremly concerned about the newest bug in iOS 18:
Whaa? That’s just shockingly dreadful!
Since the early days of the web, large corporations have seemingly always wanted more than the web platform or web standards could offer at any given moment. Whether they were aiming for cross-platform-compatibility, more advanced capabilities, or just to be the one runtime/framework/language to rule them all, there’s always been a company that believes they can “fix” it or “own” it.
Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.
The Competition & Markets Authority brings receipts:
The requirement that all browsers on the iOS operating system use a specific version of the WebKit browser engine controlled by Apple, means that there is no competition between browser engines on the platform. Browser vendors cannot switch to an alternative browser engine or make changes to the version of WebKit used on iOS. Similarly, consumers are unable to switch to a browser based on an alternative browser engine. We consider that the lack of competitive pressure is likely to reduce Apple’s incentives to improve WebKit.
Apple announced some stuff about artificial insemination at their WorldWide Developer Conference, none of which interests me one whit. But we did get a twitch of the webkit curtains to let us know what’s coming in Safari. That does interest me.
I’m really pleased to see that on desktop, websites that have been added to the dock will be able to intercept links for that domain:
Now, when a user clicks a link, if it matches the
scopeof a web app that the user has added to their Dock, that link will open in the web app instead of their default web browser.
Excellent! This means that if I click on a link to thesession.org from, say, my Mastodon site-in-the-dock, it will open in The Session site-in-the-dock. Make sure you’ve got the scope property set in your web app manifest.
I have a few different sites added to my dock: The Session, Mastodon, Google Calendar. Sure beats the bloat of Electron apps.
I have encountered a small bug. I’ll describe it here because I have no idea where to file it.
It’s to do with Spaces, Apple’s desktop management thingy. Maybe they don’t call it Spaces anymore. Maybe it’s called Mission Control now. Or Stage Manager. I can’t keep track.
Anyway, here are the steps to reproduce:
File menu or the share icon, select Add to dock.F3 key, drag that window to a desktop other than desktop 1.Options, then Assign To, then This Desktop.Expected behaviour: when I click on the icon in the dock to open the site, it will open in the desktop that it has been assigned to.
Observed behaviour: focus moves to the desktop that the site has been assigned to, but it actually opens in desktop 1.
If someone from Apple is reading, I hope that’s useful.
On the one hand, I hope this isn’t one of those bugs that only I’m experiencing because then I’ll feel foolish. On the other hand, I hope this is one of those bugs that only I’m experiencing because then others don’t have to put up with the buggy behaviour.
It’s been dispiriting but unsurprising to see American commentators weigh in on the EU’s Digital Markets Act. I really wish they’d read Baldur’s excellent explainer first.
John has been doing his predictable “leave Britney alone!” schtick with regards to Apple (and in this case, Google and Facebook too). Ian Betteridge does an excellent job of setting him straight:
A lot of commentators seem to have the same issue as John: that it’s weird that a governmental body can or should define how products should be designed.
But governments mandate how products are designed all the time, and not just in the EU. Take another market which is pretty big: cars. All cars have to feature safety equipment, which varies from region to region but will broadly include everything from seatbelts to crumple zones. Cars have rules for emissions, for fuel efficiency, all of which are designing how a car should work.
But there’s one assumption in John’s post that Ian didn’t push back on. John said:
It’s certainly possible that Meta can devise ways to serve non-personalized contextual ads that generate sufficient revenue per user.
That comes with a footnote:
One obvious solution would be to show more ads — a lot more ads — to make up for the difference in revenue. So if contextual ads generate, say, one-tenth the revenue of targeted ads, Meta could show 10 times as many ads to users who opt out of targeting. I don’t think 10× is an outlandish multiplier there — given how remarkably profitable Meta’s advertising business is, it might even need to be higher than that.
It’s almost like an article of faith that behavioural advertising is more effective than contextual advertising. But there’s no data to support this. Quite the opposite. I wrote about this four years ago.
Once again, I urge you to read the excellent analysis by Jesse Frederik and Maurits Martijn.
There’s also Tim Hwang’s book, Subprime Attention Crisis:
From the unreliability of advertising numbers and the unregulated automation of advertising bidding wars, to the simple fact that online ads mostly fail to work, Hwang demonstrates that while consumers’ attention has never been more prized, the true value of that attention itself—much like subprime mortgages—is wildly misrepresented.
More recently Dave Karpf said what we’re all thinking:
The thing I want to stress about microtargeted ads is that the current version is perpetually trash, and we’re always just a few years away from the bugs getting worked out.
The EFF are calling for a ban. Should that happen, the sky would not fall. Contrary to what John thinks, revenue would not plummet. Contextual advertising works just fine …without the need for invasive surveillance and tracking.
Tracker-driven behavioural advertising is bad for users. The advertisements are irrelevant most of the time, and on the few occasions where the advertising hits the mark, it just feels creepy.
Tracker-driven behavioural advertising is bad for advertisers. They spend their hard-earned money on invasive ad tech that results in no more sales or brand recognition than if they had relied on good ol’ contextual advertising.
Tracker-driven behavioural advertising is very bad for the web. Megabytes of third-party JavaScript are injected at exactly the wrong moment to make for the worst possible performance. And if that doesn’t ruin the user experience enough, there are still invasive overlays and consent forms to click through (which, ironically, gets people mad at the legislation—like GDPR—instead of the underlying reason for these annoying overlays: unnecessary surveillance and tracking by the site you’re visiting).
It’s a shame that the newest Safari release is overshadowed by Apple’s shenanigans and subsequent U-turn because there’s some great stuff in there.
I really like what they’re doing with web apps added to the dock:
Safari adds support for the
shortcutsmanifest member on macOS Sonoma. This gives you a mechanism in the manifest file for defining custom menu commands that will appear in the File menu and the Dock context menu.
The EU is not the FCC. I wish every American tech pundit would read and digest this explainer before writing their thinkpieces.
It’s very common for US punditry to completely misunderstand the EU and analyse it as if it were a US political entity – imagining that its actions are driven by the same political and social dynamics as a protectionist industry within the US.
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.
‘Sfunny, I’d been meaning to write a blog post on exactly this topic, but Tyler says it all …and that’s before Apple’s scandalous shenanigans.
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.
I was impressed with how Safari now allows you to add websites to the dock:
It feels great to have websites that act just like other apps. I like that some of the icons in my dock are native, some are web apps, and I mostly don’t notice the difference.
For all intents and purposes, this is a desktop application created without a single line of Swift or Objective-C, or any heavy Electron wrappers.
Oh, and the application can work offline! Service workers, and browser storage are more than stable enough to handle a variety of offline loading patterns. These are truly exciting times to be building for the web!
There was one aspect that I was particularly pleased with. External links:
Links within a Safari-installed web app respect your default browser choice.
Excellent! Except it’s no longer true. At least not in some cases. The behaviour is inconsisent but I’m running the latest version of Safari on the latest version of Sonoma, and now external links in a Safari-installed web app are broken. They just stay in the same application.
I thought maybe it was related to whether the website’s manifest file has the display value set to “standalone” rather than, say, “minimal ui”. Maybe the “standalone” instruction is being taken literally? But even when I change the value I’m still getting the broken behaviour.
This may sound like a small thing, but it completely changes the feel of using the web app. Instead of feeling like “I’m using an app that just happens to be on the web”, it now feels like “I’m using a web browser but with fewer features.”
I’ve been loving having Mastodon as a standalone app in my dock. It used to be that if I clicked on a link in a Mastodon post, it would open in my browser of choice (Firefox) where I could then bookmark it, or do any other tasks that my browser offers me. Now if I click on a link in Mastodon, I’m stuck in the same “app”. It feels horribly stifling.
I can right-click on a link and get options that still keep me in the same app, like “Open link” or “Open Link in New Window.” To actually open the link in my web browser, I have to select “Copy Link”, then go to my web browser, open a new tab, and paste the link in there.
This is broken. I hope it isn’t intentional. Maybe I’m just at the receiving end of some weird glitch. If this stays this way, I’ll probably just remove the Safari-installed web apps from my dock. They feel pointless if they’re just roach motels.
I’d love to file a bug for this, but this isn’t a Webkit bug, it’s a Safari bug (and the Webkit bug tracker is at pains to point out that Webkit and Safari are not the same thing). But have you ever tried to file a bug with Apple? Good luck!
Anyway, I sincerely hope that this change will be walked back. Otherwise websites in the dock are dead in the water.
Lots of new features landing in Safari, and it’s worth paying attention to the new icon requirements now that websites can be added to the dock:
To provide the best user experience on macOS, supply at least one opaque, full-bleed
maskablesquare icon in the web app manifest, either as SVG (any size) or high resolution bitmap (1024×1024).
These updated definitions makes sense to me:
- Newly available. The feature is marked as interoperable from the day the last core browser implements it. It marks the moment when developers can start getting excited and learning about a feature.
- Widely available. The feature is marked as having wider support thirty months or 2.5 years later. It marks the moment when it’s safe to start using a feature without explicit cross-browser compatibility knowledge.
Following on from my post about websites in the dock, Trys upgraded to Sonoma and added a handy copy’n’paste resource to his dock. It works a treat.
Sit with that for a second, you can write a desktop application with no tooling, launch it from your phone to the internet for free, and seconds later install it on any computer. I didn’t have to ask permission, or jump through any App Store hoops. I wrote a thing, pushed it to the internet, and then I could use the thing. Even better, I could send the link to Chris and he could use the thing. That’s the power of the internet.
Mobile phones and the “app economy”, an environment controlled by exactly two companies and designed to extract a commission from almost every interaction and to promote native and not-portable applications over web applications. But we also see the same behaviour from so-called “native to the web” companies like Facebook who have explicitly monetized reach, access and discovery. Facebook is also the company that gave the world React which is difficult not to understand as deliberate attempt to embrace and extend, to redefine, HTML itself.
Perversely, nearly everything about the mobile/app economy is built on, and designed to use, HTTP precisely because it’s a common and easy to implement standard free and unencumbered by licensing.
I updated my Mac to the newest operating system, Sonoma. I did this to try out the new “add to Dock” feature in Safari. It’s like the “add to Homescreen” action on iOS.
Before I get into what’s good, I have to start by ranting about a big problem on both desktop and mobile: discovery.
First of all, you have to know that a square with an arrow sticking out of it means “share”.
Okay, I can buy it. It’s no better or worse than the three horizontal lines of a hamburger icon, or the three horizontal dots of a kebab icon. And whereas the hamburger and kebab icons are used as a catch-all cupboard to sweep all your rubbish into, at least this icon has a specific meaning. It means share, right?
Well, it used to. But now it’s also home to “add to Homescreen” and “add to Dock”. Neither of those actions are sharing.
Stretching semantics, I suppose you could say you’re sharing something with yourself.
Anyway, this is the biggest issue with progressive web apps on both iOS and Mac. Regardless of how well they work, there’s not much point if most people don’t know the option exists.
(Update: Jen rightly points out that you can also get to “add to Dock” from the file menu. Doh! How did I miss that‽)
Discovery aside, I was interested to see how Safari handles web apps on desktop compared to how Chrome does it.
I’ve had one or two web apps in my dock for a while, installed through Chrome. Google Meet is one of them. I use it quite a bit, and honestly it feels no different to using a native desktop app.
One annoyance is that the Chrome browser also automatically launches whenever I launch the Google Meet icon in my dock. This wouldn’t matter if Chrome were my default browser, but I use Firefox. So whenever I’m using the Google Meet web app, there’s a Google Chrome icon hanging around in my dock, saying “gizza job, I can do that.”
I opened Google Meet in Safari and then selected “add to Dock” from the square with an arrow sticking out of it. Then I quit Safari. I was delighted to see that when I launched the Google Meet web app from the dock, it didn’t automatically launch Safari! Excellent!
Even better, links within a Safari-installed web app respect your default browser choice. What I mean is, previously when I had Google Meet installed via Chrome, if I clicked an external link in Google Meet it opened in Chrome. But now with the Google Meet installed via Safari, external links open in Firefox, my browser of choice. Very good!
But the Safari-installed version of Google Meet is, alas, over-zealous with permissions. I have to grant access to my microphone and camera every single time I launch it. Previously—with the version installed via Chrome—it remembered my choice.
Now I don’t know if the behaviour in the Safari-installed version is a deliberate choice made for security reasons, or if it’s a bug. I suspect it’s a bug. After all, on iOS you get access to more permissions if a site is added to the homescreen—it’s the only way to ask for permissions for notifications, for example.
I added a few more sites to my dock: mastodon.social and thesession.org. They both work really well as standalone apps.
Interestingly, if I click a link to thesession.org from within the mastodon.social standalone web app (or the other way around), the link opens in my default browser. So the web apps don’t “own” the domains. That’s fine, although I wonder if it violates the principle of least surprise—perhaps the expectation is that the installed web app is the preffered owner of that link.
I also tried adding Google Calendar to my dock. Ironically, I can only do this with Safari. For some reason, Google have chosen not to make their calendar a progressive web app …which means there’s no option to install it from Google Chrome.
They’re missing a trick there. It’s the perfect candidate for being a standalone app.
Actually, I take that back. Gmail is the perfect candidate for being a standalone app …and yet it’s not a progressive web app. Very odd!
With Safari, you can add any website to the dock. It doesn’t need to be a progressive web app. But the installation experience works best if there’s a manifest file pointing to some nice icons.
As it turned out, Google Calendar runs like an absolute dog in Safari (and therefore as a Safari-installed web app). Before you cry conspiracy, note that it runs absolutely fine in Firefox. I know because I use it in Firefox every day. But I can’t add it to my dock from Firefox because Mozilla turned their back on progressive web apps a while back. A bad decision.
Google Calendar isn’t the only thing that runs slowly in Safari’s engine. This page on The Session has a very large DOM and a badly-coded in-page search (I know, I know, I need to improve it). It works fine in other browsers but Safari struggles mightily.
(Update: I tried using Google Calendar from Safari again and it seems to be running just fine now. Maybe I caught it on a bad day? In any case, I’ve added it to the dock now and it’s feeling good as a standalone app.)
Still, aside from a few annoying little things around permissions and performance—and the situation with discovery—it feels great to have websites that act just like other apps. I like that some of the icons in my dock are native, some are web apps, and I mostly don’t notice the difference.
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.