> The bashing on apple for this "to sell more apps" is nonsense, Apple originally designed and intended for HTML5 apps to beat Flash.
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
They can get away with it because iOS users have a higher propensity to pay than any other platform. So it's often not a good idea to stop caring about iOS, assuming you want to make money, anyway. Even if you don't, iOS users are just different from Android and web, so they're often desirable regardless.
I feel like there are a lot of iOS/iPadOS 17 and below devices holding things back right now. Desktop browsers are in a really good standards space now with their constant and frequent nagging for users to update.
Apple is the only ones holding anything back on iOS. They forbid any browser except Safari. At least if they let Google Chrome or any other browser maker use their own browser engine, iOS could have a capable browser installed. It is one reason among many Apple is being sued by the DOJ, but so far no progress forcing them to allow other browser engines like they did in the EU.
It sounds like they were testing with iOS 12? In practice that has fallen out of use and doesn't need to be supported any more. Yes, a bunch of problems are to do with Safari specifically, but if you target relatively modern versions only (iOS 16+ is pretty reasonable IMO) it'll save a lot of pain.
Yeah, supporting iOS 12 in 2025 is odd. I was investigating browser support levels just recently for a library and also settled on iOS 16 as a reasonable level.
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 have to support iOS 16.
In terms of browser specific bugs that I have to deal with I'd say about 80-90% of what I encounter is Safari specific. Of that another 80% only affects iOS and of that like 2/3 are fixed in more current versions.
Honestly I gave up trying to support apple products a while ago - the fact that iOS and Mac lock the browser version to the os version makes it such a royal pain in the ass to support.
Interesting article which reinforces my decision to never engage with web development in any manner other than throwing WASM paint on a Canvas.
> 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.
Ok, the complaints about Apple being behind the Google "standard" are probably legitimate, as long as we keep in mind Chrome isn't a standard.
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.
At which point to you just go "fuck Apple" and choose to display a passive-agressive "This game only works on browsers with reasonable compatibility" instead? That's probably what I'd have done.
> The web has supported these basic functions for over a decade. Surely in the year 2025, I thought, HTML5 is a good choice for these simple needs.
> 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?
While this list is accurate enough, I assume the developer doesn't have to support older Android phones, because ... yeah. That's hell.
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 article is an absolute treasure trove of real problems I too have encountered on my own journey of creating an html game, and excellent solutions that I was completely unable to find on my own! I give real props for the depth of this analysis.
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!
> Browsers are designed to be the end user's self-service toolkit to combat our bad websites. Users can override fonts, mute sounds, enlarge text, pinch-zoom in, open images in a separate tab, copy-and-paste, autofill rote form inputs, switch to "simplified reading mode", search for the same information elsewhere, reload the page to reset Javascript bugs, and even try a different browser to see if they happen to have the one on their computer that we bothered to test.
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.
Quite a bit of this, mainly later on, feels unjust. Many are problems about mobile devices, not the web. Sizes don’t mean what you might expect? They don’t on any platform. A pixel hasn’t been a physical pixel reliably for at least fifteen years, and far longer in some ecosystems. Physical units never matched reality reliably, which is part of the reason they have steadily been phased out or discouraged across all platforms (Firefox’s mozmm unit is a fun piece of history: it tried to be one physical millimetre).
> 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).
In defense of Firefox, there is a reason for the iOS Firefox browser being so bad. Apple mandates all other browsers to use the WebKit rendering engine instead of their own. Firefox isn't able to use the Gecko engine. I guess Apple is afraid that others will show up the Safari browser.
> The unglamorous answer is that this might be just a documentation problem. MDN is pretty good, even though Mozilla increasingly concerns me as a steward of the open web. What if it were just a little better?
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?
38 comments
[ 4.8 ms ] story [ 57.5 ms ] threadTogether 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.
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
There are a lot of bugs where home screen safari passes feature detection but in reality does not work.
iOS and Safari are hell.
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.
> 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.
Biggest peev for me is inconsistent support for transparent (alpha channel) video
More like "+40 reasons to ignore iOS as a target when making your HTML game"
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.
> 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).
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?