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.
IMO if they had allowed Firefox onto the App Store (Mozilla have had working ports more than once AFAIK) it might have helped it hold onto market share - I think Apple is partly responsible for the Chrome monoculture.
If that were the case then why isn’t Firefox on mobile on Android more successful? Apple blocking other browser engines in iOS is the only thing preventing a complete hegemony of the web by Google/Blink.
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.
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.
Many problems in article are specific to old versions of iOS which is only in old versions of iPhone. Most old iPhone users are not potential paying customers. iOS need to be supported but old versions of iOS don't.
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.
Unity in the browser fails basic interactions like copy and paste. All WASM paint on an Canvas apps on the browser have similar issues with non-english input, accessability, integration with tihngs like dictionaries, password managers, etc...
To be clear, I am not suggesting the WASM canvas approach for ordinary web pages. WASM is for things that are unto themselves full-fledged applications, with the convenience of instant access to running them in a sandbox on any platform. The game described in the article certainly makes more sense with WASM than HTML5, as it uses web APIs for doing something that isn't displaying a standard web page but instead needs to conform to a specific set of characteristics to provide a consistent and polished user experience. And while Unity doesn't, features like canvas copy-pasting can be implemented manually or by another framework.
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.
> 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
I think it's fair to say that Safari is no longer late.
That comes with 3 caveats.
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.
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.
IMO if they had allowed Firefox onto the App Store (Mozilla have had working ports more than once AFAIK) it might have helped it hold onto market share - I think Apple is partly responsible for the Chrome monoculture.
If that were the case then why isn’t Firefox on mobile on Android more successful? Apple blocking other browser engines in iOS is the only thing preventing a complete hegemony of the web by Google/Blink.
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.
this felt not as a "50 problems in web api" list, but more like "50 reasons to stop caring about iOS and just leave it rotting"
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.
Many problems in article are specific to old versions of iOS which is only in old versions of iPhone. Most old iPhone users are not potential paying customers. iOS need to be supported but old versions of iOS don't.
Safari - Internet Explorer of 2025
I could probably give another 50 as could everyone else reading
Biggest peev for me is inconsistent support for transparent (alpha channel) video
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.
Unfortunately web API doesn't yet allow drawing multi-line text in canvas. To draw multi-line text in canvas you need a layouting library
Unity in the browser fails basic interactions like copy and paste. All WASM paint on an Canvas apps on the browser have similar issues with non-english input, accessability, integration with tihngs like dictionaries, password managers, etc...
So, no, do not do Wasm + Canvas
To be clear, I am not suggesting the WASM canvas approach for ordinary web pages. WASM is for things that are unto themselves full-fledged applications, with the convenience of instant access to running them in a sandbox on any platform. The game described in the article certainly makes more sense with WASM than HTML5, as it uses web APIs for doing something that isn't displaying a standard web page but instead needs to conform to a specific set of characteristics to provide a consistent and polished user experience. And while Unity doesn't, features like canvas copy-pasting can be implemented manually or by another framework.
I'm so glad every time I see something like this that I don't do webdev for a living.
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.
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.
It's absolutely amazing the degree to which Apple has recapitulated the Internet Explorer debacle of thirty years ago.
The full screen thing -- have you tried saving the SPA to the home screen?
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.
> 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
Interestingly enough Apple has put a ton of effort into Safari recently and have shot up to the top of the interop leaderboards.
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.
I think it's fair to say that Safari is no longer late. That comes with 3 caveats.
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.
And what else can drive priorities for software development in a company with virtually infinite resources?