It used to be true, but the last time I saw evidence was in 2015 or thereabouts.
Is it still true in (almost) 2026, though?
Facebook's Threads app has more activity on iOS than Android[1].
---
On the other hand, the default on Android is Chrome so there may be less motivation to change since it's the 'default' platform to target. But if Apple opened up iOS to other browsers, the likely outcome would not be Firefox gaining market share but Chrome completely taking over.
I do not like that iOS doesn't allow for alternative engines but I appreciate that it's basically the only thing that even somewhat reigns Google in.
If Apple didn't purposely hobble Safari and forbid other browser engines so that developers had no choice but to develop an app for the app store where Apple can then skim 30% off all purchases, there wouldn't be as much of a need to allow other browser engines. For Apple it's completely about greed.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
I acknowledge my privilege.
Oh wait that’s totally not the case. The fact is that the web sucks as an app platform for mobile.
That isn't a fact, that's only your opinion.
For reference, iOS 12.x and below are used 0.33% globally https://browsersl.ist/#q=safari+%3C+13+or+ios+%3C+13. Selecting iOS 16 would still exclude less than 1% globally https://browsersl.ist/#q=safari+%3C+16+or+ios+%3C+16. In both cases the vast majority would be older iOS which is unfortunate because I assume they're on older devices with no upgrade path, but you have to decide on the transpile/polyfill cutoff at some point and browser support has an extremely long tail.
I've cross-compiled code for mobile before, and I've made personal websites before. I sure wouldn't want to do that for a living.
MacOs is slightly more forgiving in that the last 2 versions can get the latest safari. However, people tend to keep a computer a lot longer than a phone and many don't or can't update macOS, so it's not much better.
> But a purpose-built game framework like Unity would have polyfill to protect you from more of these layout and audio problems
Unity doesn't polyfill, it just relies on WASM for everything which results in significantly more consistent behaviour provided your browser supports WASM to begin with.
> Unity and Godot might be better choices, but I have no experience with them and I assume they only make sense for games.
Unity has been used for non-game purposes successfully, and there are also other WASM-compatible frameworks specifically targeting non-game GUI use cases.
So, no, do not do Wasm + Canvas
Also, while Unity doesn't, features like canvas copy-pasting can be implemented manually or by another framework. Non-English input works fine with WASM; if it doesn't render, it's because the application developer didn't include a font that supports those characters, since there's no fallback-font kind of thing going on. But this stuff is exactly the same as developing any kind of non-web application; if the framework doesn't provide a feature, you have to provide it yourself. It needs to be approached from an application development perspective rather than a web development perspective; you don't get the freebies of web, both the good and the bad, but this gives you much more control and capability.
Also, I think you're under estimating the amount of work required. No one wants your custom solutions. They want the OS solution. They want their OS IME that they use in every app, not the one you built from scratch for your "blat pixels to the page" app. They want their passkeys from their OS, which are only available via web features and are not available from "blat pixels to the page" apps. They want their auto correct to use all the words in their local OS dictionary but that's not available to "blat pixels to the page" apps. I could list several more issues like this
> The only reason to use the web is because it reaches everywhere. you then hoble it by making it not work in 2/3rds of the world you might as well have just shipped a native app.
I also think this is a ridiculously reductionist take. While I myself consider language support a priority (and incidentally, happen to believe for instance most Linux distros have long kneecapped the spread of Linux by not being accessible to non-Latin users) [and conversely believe WASM does not hobble language support, otherwise I would not be interested in it], that is not even close to "the only reason" to use the web. There are plenty of people in the world who host websites in only their native language. Even if you don't care to support foreign languages, deploying to the web gives you (a) instant cross-platform support with comparatively low effort and (b) zero friction to users, who can instantly use your application without an installation process which itself entails security risks. Would the use of WASM for a niche English text adventure put off Chinese users who might otherwise play the game if only it was written in HTML5? Probably not, they were never going to play the game in the first place.
Biggest peev for me is inconsistent support for transparent (alpha channel) video
The article gets to the right conclusion, develop mobile first. I'd put it more generally as develop for the most constrained devices you intend to support. If they had done so, it would have saved a lot of time (some of their expectations about APIs still would not have been met).
More like "+40 reasons to ignore iOS as a target when making your HTML game"
It's been a few years since I've had battle Safari quirks, one example that stuck with me from a couple of years ago is that LocalStorage is not available in private browsing mode. Other browsers just treat it as ephemeral/SessionStorage basically.
Also I remember our Sentry being _littered_ with random React internals throwing (it was like a couple of different things), but it was only ever iOS that had those issues.
Running a browser on an OS that doesn’t get security updates doesn’t sound like a winning combination.
As much as IE6 was a menace for not keeping up with standards, what made it really bad was crap like ActiveX, radially different layout/rendering behaviors, and shortcomings like inability to render transparency in PNGs and some of the most illegible italic text rendering I’ve ever seen.
I do not know enough to tell whether this means that modern Safari has finally stopped being the new IE6, or that she is just doing marketing that misleadingly focuses on some features, while other, more frustrating and more deeply rooted, issues remain.
so what's the spec say people should do? Does it not specify?
Well I have known a few things on accessibility and color spaces where Safari was way ahead for a good length of time so my theory has always been that they were ahead on the things they cared about and behind on the things that they didn't care about and depending on what you cared about they might seem like jerks or heroes.
Google and Mozilla by contrast don’t need to care as much about these things since they’re not going to take as much heat for poor battery life or color handling; on the platforms that most of their users are on, these are both the rule and not the exception so users don’t really protest.
Instead what Google cares the most about is asserting control over the web as a platform, which is directly reflected by the features they’ve prioritized.
Correction: it’s not available in Firefox either, throws on get/set. It’s the Chromium family that’s the odd one out, but it’s so popular and testing in other browsers’ private windows so uncommon that developers often don’t realise that localStorage is fallible.
Standard Web in 2025 is whatever Google decides to implement on Chrome, and all existing forks downstream from it, including Electron crap.
But the part about a virtual mouse cursor so you have hover... no. No no and no. No on Apple, no on Android, no on any touch only device.
The iPhone took the world by storm because they designed their UI for fat finger touch only. Back then, Google speed redesigned their unreleased Android along the same paradigms when they saw how easy the Apple solution was to use.
If you have a mouse heavy game, no matter if you do it in native code or html, you have to have different interfaces for touch and mouse/kb if you want it to be playable.
Just say Chrome. This is what you mean.
> What really happened was, I hit over 50 surprising problems related to gaps in web standards, requiring me to spend over half of the total development time
The half part might be surprising, but the fact that the web is broken in all the big and little places shouldn't really be, isn't that part of deep web lore that you get even by looking at the omnipresent dom tree, but especially if you're a druid and forest-native?
Like, "No you can't control the real size of anything" has been one of the many fundamental cascading flaws of that peculiar joke of a design system since forever, no?
But it is interesting that most of the listed issues that are genuine bugs are fairly minor, while the show-stoppers are largely Apple trying to protect user's from bad actors.
Which, as a developer, I hate. But as a user, I appreciate.
Surfing the web on my Android devices is absolute madness in certain segments of the web.
>This is not because iPhones are good, it's because they're bad
This just confirmed my biases and suspicions that iPhone is very much overrated technologically and essentially toxic to the mobile open eco-system.
Perhaps the only saving grace is that in the early days Apple with iPhone was promoting standard HTML instead of proprietary system like Adobe Flash.
I would like to re-emphasize the author’s point that the mobile web begins to struggle with anything beyond a Wikipedia page about raccoons. I feel this point was understated!
Consider realtor.com (and many others) where zooming in a picture causes everything but the picture to zoom! Insane when you consider how much houses cost. What about on shopify—type websites, where everything scrolls left when you try to swipe left to activate the carousel of pictures. How often I wish they would design these sites as they would a Wikipedia article on raccoons — as bare bones as they can get!
To be fair, part of this is that a "good website" for a web developer is often a "bad website" for a user. Giving users the ability to work around bad websites is good for users and if this makes "good experiences" hard to write, I think its a small price to pay. So much of web development is finding ways to combat the users (to track them, show them ads, prevent them from using the site how they want). I think web browsers should keep providing features for users to fight back rather than simply being tools of web developers.
> One way we could have ensured that designs are accessible is to make it impossible to build anything else.
The only way of achieving this is by hobbling the web in a way that I guarantee would have killed it.
> The <input> tag is like 30 years old, but that has apparently not been enough time for us to figure out how to make it usable!
It was enough time. <input> was fine. But then devices without physical keyboards came along, and ruined it.
You’ll have the same problems if you try adding text input to your landscape mobile game using the platform’s native toolkit. In these areas, the web is not the problem: phones are, due to their limited screen size and different input methods; and mixed-input devices/platforms are—Windows two-in-ones are full of touch/pen niggles Android doesn’t have, whether you’re web or native (and Android with a pointer has issues in the other direction).
Maybe the default text input method on touchscreens should be dictation.
Let Safari die already.
When I first read this, I read it like "Here's 50 problems that have standard web APIs"...that solve the problems!
As in, "here's problem 27, and here's the API to solve it".
Mind, I haven't read that article, and that's not what it's about.
Just how I read the headline. Just interesting how the language center can work.
What if it had a comment section where people could discuss these issues, like the PHP docs? What if it had a wiki, where people could collaborate on fixing them, like ArchWiki?
https://apidock.com/ruby/String/split
Though, considering how much information tends to get centralized in these comments, I think the wiki-like direction is the way to go. (I know anyone can edit MDN, but it's via github PRs rather than being able to make quick edits on the site.)
PS: MDN and MSDN are my favorite documentation sites.
I've pointed out errors a couple of times and they were corrected pretty quickly.
When I pointed out some bugs on Microsoft's docs they just basically replied "hurry up and fix them then!" which annoyed me at first, but they actually poked me until I stopped being lazy and submitted a PR, wherein I actually learned some new things.
One of them "self-aware wolves", I see. How did the author wish things to work? That websites should be able to micromanage the user experience without restraint while indulging in whatever abusive behaviours they please, that the user should be powerless against?
And to be "on topic", have you considered making UI more "web app" like, e.g. something more akin to large enterprise CRUD system with tables and menus, that might be more suited for such interfaces, in stead of your own custom UI solution?
Terretta•1mo ago
Together with some meta tags, that launches full screen and stays full screen, like an app.
The bashing on apple for this "to sell more apps" is nonsense, Apple originally designed and intended for HTML5 apps to beat Flash.
One of the earliest games for iPhone was PacMac, it was a SPA web app saved to home screen, it worked great.*
OTOH, in 30 years of web dev, I never got pages about raccoons to work either.
* Haven't checked this lately to see if they deprecated this.
brailsafe•1mo ago
Whatever their apparent intention might have been ~15 years ago, it would be hard to argue that Apple puts a lot of resources into trying to protect its fiefdom. I don't think it would be all that different to suggest they (Apple) wouldn't try to control how people pay for apps by preventing app developers to offer a web-based payment option, on the basis of their past relationship with HTML5. A huge component in their success with iPhones has been control over the entire supply chain.
That said, it is a somewhat conspiratorial take that is probably better explained by laziness, bad choices, and control over proprietary UX patterns (that suck), than generalized competition, but it's not much of a reach. They also compute localStorage limits differently and have always diverged for stupid reasons
llmslave2•1mo ago
https://wpt.fyi/interop-2025?stable
I don't really buy the conspiratorial takes either. I think they just had different priorities for their browser.
darkwater•1mo ago
YmiYugy•1mo ago
1. Safari isn't updated independently of the OS, so users who don't update or whose iPhones don't get updates anymore will be forever stuck on old Safari versions.
2. Being timely on new features does little to alleviate the pain that comes from all the old messiness.
3. Different priorities driven by economic incentives of protecting their 30% cut. Fair enough. But shutting out alternative web engines on iOS is definitely a dick move.
mdhb•1mo ago
When they were asking for community input as to what developers wanted to be a part of interop 2025 that then had to go for a further non-public round with the browser makers.
Apple then proceeded to veto all of the most popular suggestions and insist that then running grep over their codebase in order to fix a comparability bug [1] with chrome and Firefox version 1 was somehow a legitimate contribution precisely so they could game the interop stats that you’re citing here.
The moment you look at the real statistics (https://wpt.fyi/results/?label=master&label=experimental&ali...) where Apple can’t game the system the story becomes much clearer and the criticism much more justified.
[1] https://web.dev/blog/interop-2025 (scroll down to the text decoration topic)
JimDabell•1mo ago
This is misleading. The “real statistics” you link to include non-standard, Blink-only APIs like Web Bluetooth and Web USB. These are not web standards. Google proposed them and both Mozilla and Apple have rejected them on security and privacy grounds. Google have not been able to convince anybody to implement them.
Web standards are not simply whatever Google unilaterally decide they want. Standards require consensus.
sccxy•1mo ago
There are a lot of bugs where home screen safari passes feature detection but in reality does not work.
iOS and Safari are hell.