In Loving Memory of Square Checkbox

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

…every major OS vendor has been adhering to the convention that checkboxes are square and radio buttons are round.

Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round checkboxes.

Four "round" checkboxes, two of them checked.
Apple Design Resouces — visionOS — Library

Anyway, with Apple’s betrayal, I think it’s fair to say there’s no hope for this tradition to continue.

I therefore officially announce 2024 to be the year when the square checkbox has finally died.

The Web did a bad enough job of making checkboxes and radiobuttons inconsistent. I’m not saying you can’t style them, Web developers, but let’s at least keep the fundamental shape of them the way that they have been for decades so that users can understand them!

But yeah, Apple’s new designs could spell the beginning of the end of this long-established standard. Sad times.

×

Chrome is the new Safari. And so are Edge and Firefox.

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I am not saying Apple’s approach is wrong. What Apple is doing is important too, and I applaud the work Apple has been doing in improving privacy on the web.

But it can’t be the only priority. Just imagine what the web would look like if every browser would have taken that approach 20 years ago.

Actually, no, don’t imagine it all. Just think back at Internet Explorer 6; that is what the web looked like 20 years ago.

There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete.

As a reminder, Safari is the only web browser on iOS. You might have been fooled to think otherwise by the appearance of other browsers in the App Store or perhaps by last year’s update that made it possible at long last to change the default browser, but it’s all an illusion. Beneath the mask, all browsers on iOS are powered by Safari’s WebKit, or else they’re booted from the App Store.

Comic showing Scooby-Doo character Fred removing the mask from the ghosts of different iOS web browsers to find Safari's WebKit beneath all of them.

Neils’ comparison to Internet Explorer 6 is a good one, but as I’ve long pointed out, there’s a big and important difference between Microsoft’s story during the First Browser War and Apple’s today:

  • Microsoft bundled Internet Explorer with Windows, raising the barrier to using a different web browser, which a court ruled as monopolistic and recommended that Microsoft be broken into smaller companies (this recommendation was scaled back on appeal).
  • Apple bundle Safari with iOS and prohibit the use of any other browser’s rendering engine on that platform, preventing the use of a different web browser. Third-party applications have been available for iOS – except, specifically, other browser rendering engines and a handful of other things – for 13 years now, but it still seems unlikely we’ll see an antitrust case anytime soon.

Apple are holding the Web back… and getting away with it.

×

Apple just killed Offline Web Apps while purporting to protect your privacy

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

On the face of it, WebKit’s announcement yesterday titled Full Third-Party Cookie Blocking and More sounds like something I would wholeheartedly welcome. Unfortunately, I can’t because the “and more” bit effectively kills off Offline Web Apps and, with it, the chance to have privacy-respecting apps like the prototype I was exploring earlier in the year based on DAT.

Block all third-party cookies, yes, by all means1. But deleting all local storage (including Indexed DB, etc.) after 7 days effectively blocks any future decentralised apps using the browser (client side) as a trusted replication node in a peer-to-peer network. And that’s a huge blow to the future of privacy.

Like Aral and doubtless many others, I was initially delighted to see that Safari has beaten Chrome to the punch, blocking basically all third-party cookies through its Intelligent Tracking Protection. I don’t even routinely use Safari (although I do block virtually all third-party and many first-party cookies using uMatrix for Firefox), but I loved this announcement because I knew that this, coupled with Google’s promise to (eventually) do the same in their browser, would make a significant impact on the profitability of surveillance capitalism on the Web. Hurrah!

But as Aral goes on to point out, Apple’s latest changes also effectively undermines the capability of people to make Progressive Web Applications that run completely-offline, because their new privacy features delete the cache of all offline storage if it’s not accessed for 7 days.

PWAs have had a bumpy ride. They were brought to the foreground by Apple in the first place when Steve Jobs suggested that something-like-this would be the way that apps should one day be delivered to the iPhone, but then that idea got sidelined by the App Store. In recent years, we’ve begun to see the concept take off again as Chrome, Firefox and Edge gradually added support for service workers (allowing offline-first), larger local storage, new JavaScript interfaces for e.g. cameras, position, accelerometers, and Bluetooth, and other PWA-ready technologies. And for a while I thought that the day of the PWA might be drawing near… but it looks like we might have to wait a bit longer.

I hope that Google doesn’t follow Apple’s lead on this particular “privacy” point, although I’m sure that it’s tempting for them to do so. Offline Web applications have the potential to provide an open, simple, and secure ecosystem for the “apps” of tomorrow, and after several good steps forwards… this week we took a big step back.

Spoiled by the Web

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Back in 2016, I made an iMessage app called Overreactions. Actually, the term “app” is probably generous: It’s a collection of static and animated silly faces you can goof around with in iMessage. Its “development” involved many PNGs but zero lines of code.

Just before the 2019 holidays, I received an email from Apple notifying me that the app “does not follow one or more of the App Store Review Guidelines.” I signed in to Apple’s Resource Center, where it elaborated that the app had gone too long without an update. There were no greater specifics, no broken rules or deprecated dependencies, they just wanted some sort of update to prove that it was still being maintained or they’d pull the app from the store in December.

Here’s what it took to keep that project up and running…

There’s always a fresh argument about Web vs. native (alongside all the rehashed ones, of course). But here’s one you might not have heard before: nobody ever wrote a Web page that met all the open standards only to be told that they had to re-compile it a few years later for no reason other than that the browser manufacturers wanted to check that the author was still alive.

But that’s basically what happened here. The author of an app which had been (and still did) work fine was required to re-install the development environment and toolchain, recompile, and re-submit a functionally-identical version of their app (which every user of the app then had to re-download along with their other updates)… just because Apple think that an app shouldn’t ever go more than 3 years between updates.