The cognitive dissonance of anti-web and anti-choice rules made & justified because device resource scarcity [1] against the marketing of ALL POWERFUL CPUs [2] is dizzying.
For a sense of scale, when the anti-choice, anti-web rules were laid down, Apple's fastest device was the iPhone 3G; a single-core, 32bit, in-order, ~400MHz chip attached to 128MiB of system memory.
Today, the slowest device you can buy directly from Apple is based on the A12...
The A12 is a 64 bit, 6-core, 2-and-change-GHz part with ~~8MiB of L2 cache~~ attached to 3GiB of RAM in the most resource-impoverished device Apple markets today:
Lots of web hosting services will happily sell you VPSes with fewer resources than this device. Nearly all Chromebooks and Android devices are slower. And yet, somehow, they manage to handle real browser choice.
Miraculous!
Just how head-spinning is Apple's now-slowest device compared to when the anti-web rules were laid down? We can get a rough sense.
Geekbench doesn't have data before the iPhone 4S, but it's safe to say it was between 2x and 4x faster than the 3G: gsmarena.com/compare.php3?&…
And we can compare the 4S to the XR more directly:
Trying again: Apple's iOS store shenanigans include a subtle & unique catch-22 journalists should grok:
- when apps violate policy, Apple says "use the web"
- ...except every iOS browser is required to use Apple's engine...
- ...and it's Apple keeps it year behind
This is hidden from view because no iOS browser maker dares to submit a browser that shows a "this isn't _real_ Firefox" (e.g.) banner...because what is the user supposed to do? Buy a new phone? They also can't afford to be cut off from all the world's rich users.
But why is Apple's engine & browser years behind?
Because Apple doesn't fund the WebKit team with anything like the headcount they'd need to keep up. And let's keep in mind that this isn't down to some sort of cash crunch.
Now imagine a world where Apple hadn't cut off the web at the knees and the things we regularly do on Android were possible, e.g.: WebGL 2, WASM threads (soon), Audio Worklets, large media storage, prompted PWA install, push notifications -- not to mention the upcoming stuff...
Increasingly distracted by the Performance Inequality Gap: the difference between those in the high-performance bubble thinking they're increasing richness without decreasing reach, but who are actually tanking reach by making content inaccessibly slow.
Users with the fastest devices and networks -- which includes ~all developers and business decision makers -- are leaning into technologies (JS) that, by their very nature, are decreasing the reach and usability of their services for users outside the bubble.
These devs & managers benefit from the Performance Inequality Gap in many (often indirect) ways, but not nearly as much as their now-margninalized users (and their businesses) lose.
There seems to be confusion about how, exactly, Apple keeps the web second-class on iOS. Understandable! It's the interplay of several interlocking effects. Let's examine them (thread).
First, no matter how app-like it is, Section 4.2 of the App Store Review Guidelines excludes web experiences from being discovered via the search box where users go to add things to their homescreen.
Next, Apple under-invests in Safari's engine (WebKit) in ways that cumulatively make it difficult to do anything new and ambitious. The cumulative effect of the under-investment is hard to overstate, but it can be graphed:
It's infinitely frustrating to see press coverage of HKmap.live that doesn't *actually link to HKmap.live* which is a real, bona-fide website that does the job.
This article has *25* other links, but doesn't actually link to HKmap.live