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).
Web as a platform is universally deployed on mobile devices. Whether it is theoretically impeccable or not (heh), the way it works in practice is such that it does not isolate the author from the shortcomings of the target native platform. Though it tries to, and it sort of promises that in the standards, it fails to consistently deliver, especially on iOS where Apple virtually does not allow competition. Such is the sad reality of the web platform.
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!
I've been saying this for years, and it gets down voted occasionally, but safari/webkit feels like the new IE6. I know Chrome is very bullish with adding extra features and is aggressively pushing some standards, but I've rarely had to write "workarounds" or hacks for Chrome when writing web-standard compliant code for other browsers, but I've had to frequently do it for Safari.
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.
> LocalStorage is not available in private browsing mode. Other browsers just treat it as ephemeral/SessionStorage basically.
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.
>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.
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.
Yeah, more than anything, up until recently the WebKit team primarily worked on things that Apple cares about, which is why for example it’s generally been more battery friendly than Gecko or Blink — Apple sells an absurd number of battery powered mobile devices, so they’ve got a powerful motivator to pay more mind to efficiency than most. Similarly, poor color space handling reflects badly on their devices’ displays and makes it more difficult to seamlessly blend WebViews in alongside native components.
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.
I haven't looked into this deeply; but for several years now Jen Simmons has been posting stats in which Safari is either the top scorer for interop, or is very close to the top. For example: https://front-end.social/@jensimmons/115749303356986835
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.
Chrome probably has the benefit of being updated frequently rather than more of an annual cycle. But Safari still isn't anywhere near IE6 levels of awfulness.
WebKit also isn’t trying to push a proprietary OS-locked runtime for interactivity, doesn’t wildly diverge in most rendering behavior, and handles most basics correctly.
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.
> 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.
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.
If a web browser doesn't support an API, they're essentially saying: If you want to do this, you have to make people install a native app. And the websites reponse is: Fine, I'll make people install a native app: Chrome.
Me too! If you want to do cool things with a web browser, you sure can't do it with Safari. And how many times have you been told you need to install a specific app to access a specific service? For me it's too many to count.
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.
I could be entirely off base, but I would expect Android to be more likely to have more users that would go out of their way to use a non-default web browser, given that it seems to be favored by people who like customizing things. The relative openness of the platform invites a different demographic.
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.
Yes and that’s why there are such great web apps for Android and companies that make apps for iOS just tell Android users to use the web because the web experience on Android is so great.
Oh wait that’s totally not the case. The fact is that the web sucks as an app platform for mobile.
No it isn't. People should be free to use software they like, and not get subterfuge like they get from Apple. What Apple has now is a total monopoly on iOS browsers. It's far worse than what Microsoft did to get sued for antitrust violations when they simply bundled IE with Windows - at least Microsoft didn't forbid installation of any other browser engine like Apple is doing on iOS.
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.
iOS Safari's reader mode heuristics has always been mediocre at best, and it's getting less useful by the day as more publications knowingly cripple it. It used to be that you can get around some soft paywalls with reader mode, especially if you turn on "Use Reader Automatically" which distills the content before JavaScript kicks in to remove it. Nowadays that works on fewer and fewer commercial websites, and the other day I noticed something truly shocking on a pretty mainstream tech publication (don't remember which one unfortunately): I can see like two paragraphs of content before the paywall, but when I turn on reader mode, the content shown is literally a list of Christmas laptop deals (that is not visible on the non-reader page), with the title being the only relevant thing.
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.
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.
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.
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.
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.
Linus and Luke talked about this recently during the WAN show. The gap shrunk a little, but is still huge, on the order of 5–6 times the spend per user, when it used to be 8–9 times.
Especially when you don't approach it that way; they made an HTML game in desktop Chrome then worked on getting it to work in various mobile browsers, including quite old ones.
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).
> 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?
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.
I had the same thought about the idea that Safari is “behind”. My hypothesis is that features only “exist” to people if they are implemented in Chrome. If a feature exists in WebKit but not in Chrome, nobody talks about it.
> 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.
Unfortunately this is more misdirection from Apple.
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.
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.
> Jim once again you are jumping in to defend Apple no matter what the topic is. It’s a really strange behaviour yet again.
Is it possible for you to respond to me without personal attacks? This is the second time this week you have decided it’s appropriate to call me weird.
I have not misread anything. Web USB and Web Bluetooth are not web standards.
> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
The specifications literally tell you they aren’t standards.
They have been rejected by both Mozilla and WebKit:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
> The low-level nature of this API means that it is insecure, has a massive privacy risk, and perhaps most importantly doesn't meet the web platform's device-independence bar.
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label. This spec also depends on a specific hardware technology, and enables dependency on specific attached hardware accessories, which risks the device independence of the web; thus concerns: device-independence.
Something isn’t a web standard just because Google decided to publish a specification. No other rendering engine has accepted these specifications.
> I don’t know why you keep glossing over this no matter how many times it has been politely pointed out to you.
I don’t believe anybody has ever said this to me before, let alone repeatedly, let alone politely, but perhaps I am forgetting. Could you refresh my memory? When did this happen?
> 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?
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.)
I don’t see a problem with the github PR workflow for updating documentation. Yes, it’s one step more, but it’s nothing special when you use github’s online editor.
PS: MDN and MSDN are my favorite documentation sites.
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.
Amazing game, with all that effort put in you definitely deserve some compensation for it. Have you considered uploading your game to itch.io and adding an option for players to tip you? Bonus points for not using any "gen ai" nonsense. And especially huge kudos for detailed hint system. Can't wait for your next game.
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?
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.
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.
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.
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
You appear to be misinformed. OS-level features like IMEs and dictionaries work in WASM as they do with any native application. There is nothing special about HTML elements that enables them in a way that doesn't work with WASM; they are, after all, OS features, not HTML features, and the browser is just another native application. If somebody chooses not to integrate OS features in their application, that's a reason not to use their application, but it really has nothing to do with WASM in any way whatsoever.
> 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.
You appear to be mis-informed. Or maybe there's some mis-communication going on. WASM using HTML (ok, everything works), WASM using canvas doing all input and rendring (doesn't work). As just one simple example, the browser, in a textarea or input type=text can integrate with the OS's user dictionary for auto-correction. Your WASM app using draw to pixels can not, as reading the user's dictionary is a privacy violation. Similar issues exist for all of the other topics.
> Browsers are designed to be the end user's self-service toolkit to combat our bad websites.
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?
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.
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.
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.
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.
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).
Web as a platform is universally deployed on mobile devices. Whether it is theoretically impeccable or not (heh), the way it works in practice is such that it does not isolate the author from the shortcomings of the target native platform. Though it tries to, and it sort of promises that in the standards, it fails to consistently deliver, especially on iOS where Apple virtually does not allow competition. Such is the sad reality of the web platform.
Surely the web cannot be blamed for Apple refusing to support the web.
> It was enough time. <input> was fine. But then devices without physical keyboards came along, and ruined it.
Maybe the default text input method on touchscreens should be dictation.
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!
I kinda feel like "Fifty problems with standard web APIs in 2025" is an inaccurate title.
More like "+40 reasons to ignore iOS as a target when making your HTML game"
I've been saying this for years, and it gets down voted occasionally, but safari/webkit feels like the new IE6. I know Chrome is very bullish with adding extra features and is aggressively pushing some standards, but I've rarely had to write "workarounds" or hacks for Chrome when writing web-standard compliant code for other browsers, but I've had to frequently do it for Safari.
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.
> LocalStorage is not available in private browsing mode. Other browsers just treat it as ephemeral/SessionStorage basically.
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.
>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.
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.
Yeah, more than anything, up until recently the WebKit team primarily worked on things that Apple cares about, which is why for example it’s generally been more battery friendly than Gecko or Blink — Apple sells an absurd number of battery powered mobile devices, so they’ve got a powerful motivator to pay more mind to efficiency than most. Similarly, poor color space handling reflects badly on their devices’ displays and makes it more difficult to seamlessly blend WebViews in alongside native components.
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.
I haven't looked into this deeply; but for several years now Jen Simmons has been posting stats in which Safari is either the top scorer for interop, or is very close to the top. For example: https://front-end.social/@jensimmons/115749303356986835
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.
If that is your source, then Safari was _way_ behind for all of 2025 up until this month, where it suddenly caught up.
True; I was too fascinated by the big green numbers to pay proper attention to the chart below them. Good for them that they finally caught up.
Chrome probably has the benefit of being updated frequently rather than more of an annual cycle. But Safari still isn't anywhere near IE6 levels of awfulness.
Safari adds support for new web features in point releases throughout the year.
But only for the latest major iOS version.
The latest version of iOS supports the iPhone 11 introduced in 2019.
And I use PCs way older than that with no issue. 6 years isn't that long
And what Android phones from 2019 are still getting updates?
Browser updates? Most of them.
The latest version of Android Google Chrome requires Android 10. But to keep getting updates you need Android 11.
Running a browser on an OS that doesn’t get security updates doesn’t sound like a winning combination.
More winning than updating neither
WebKit also isn’t trying to push a proprietary OS-locked runtime for interactivity, doesn’t wildly diverge in most rendering behavior, and handles most basics correctly.
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.
> 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.
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.
I can’t wait for websites to tell me I need to install Chrome on my phone.
If a web browser doesn't support an API, they're essentially saying: If you want to do this, you have to make people install a native app. And the websites reponse is: Fine, I'll make people install a native app: Chrome.
Me too! If you want to do cool things with a web browser, you sure can't do it with Safari. And how many times have you been told you need to install a specific app to access a specific service? For me it's too many to count.
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.
Different platforms, different tastes.
Facebook's Threads app has more activity on iOS than Android[1].
---
[1] https://pxlnv.com/linklog/threads-android-ranking/
I could be entirely off base, but I would expect Android to be more likely to have more users that would go out of their way to use a non-default web browser, given that it seems to be favored by people who like customizing things. The relative openness of the platform invites a different demographic.
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.
People can hardly wait to get ChromeOS Platform it seems.
I’m typing this in Vivaldi on my iPhone 11 in the UK.
I acknowledge my privilege.
you can get Vivaldi outside the UK, the issue is the web engine, is it different in the UK?
Yes and that’s why there are such great web apps for Android and companies that make apps for iOS just tell Android users to use the web because the web experience on Android is so great.
Oh wait that’s totally not the case. The fact is that the web sucks as an app platform for mobile.
>The fact is that the web sucks as an app platform for mobile.
That isn't a fact, that's only your opinion.
Yet another step towards a total Google monopoly, yay!
No it isn't. People should be free to use software they like, and not get subterfuge like they get from Apple. What Apple has now is a total monopoly on iOS browsers. It's far worse than what Microsoft did to get sued for antitrust violations when they simply bundled IE with Windows - at least Microsoft didn't forbid installation of any other browser engine like Apple is doing on iOS.
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
Speaking of iOS holding things back, my iPhone’s Safari doesn’t offer a reader for this post. Not sure why.
iOS Safari's reader mode heuristics has always been mediocre at best, and it's getting less useful by the day as more publications knowingly cripple it. It used to be that you can get around some soft paywalls with reader mode, especially if you turn on "Use Reader Automatically" which distills the content before JavaScript kicks in to remove it. Nowadays that works on fewer and fewer commercial websites, and the other day I noticed something truly shocking on a pretty mainstream tech publication (don't remember which one unfortunately): I can see like two paragraphs of content before the paywall, but when I turn on reader mode, the content shown is literally a list of Christmas laptop deals (that is not visible on the non-reader page), with the title being the only relevant thing.
The ai detected it was talking poorly about it and decided to retaliate.
Yeah, as long they are Chrome forks.
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.
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.
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.
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.
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.
> They can get away with it because iOS users have a higher propensity to pay than any other platform.
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?
Linus and Luke talked about this recently during the WAN show. The gap shrunk a little, but is still huge, on the order of 5–6 times the spend per user, when it used to be 8–9 times.
I think the lesson is that writing a mobile game using HTML is still tricky. Few of these issues would come up when writing a web page.
Especially when you don't approach it that way; they made an HTML game in desktop Chrome then worked on getting it to work in various mobile browsers, including quite old ones.
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).
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.
It has its pros and cons and can be challenging, but I enjoy it.
> 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?
Safari - Internet Explorer of 2025
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.
I had the same thought about the idea that Safari is “behind”. My hypothesis is that features only “exist” to people if they are implemented in Chrome. If a feature exists in WebKit but not in Chrome, nobody talks about it.
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.
Unfortunately this is more misdirection from Apple.
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)
> 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.
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.
[flagged]
> Jim once again you are jumping in to defend Apple no matter what the topic is. It’s a really strange behaviour yet again.
Is it possible for you to respond to me without personal attacks? This is the second time this week you have decided it’s appropriate to call me weird.
I have not misread anything. Web USB and Web Bluetooth are not web standards.
> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://webbluetoothcg.github.io/web-bluetooth/
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/webusb/
The specifications literally tell you they aren’t standards.
They have been rejected by both Mozilla and WebKit:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
— https://mozilla.github.io/standards-positions/#web-bluetooth
> The low-level nature of this API means that it is insecure, has a massive privacy risk, and perhaps most importantly doesn't meet the web platform's device-independence bar.
— https://github.com/WebKit/standards-positions/issues/570#iss...
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
— https://mozilla.github.io/standards-positions/#webusb
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label. This spec also depends on a specific hardware technology, and enables dependency on specific attached hardware accessories, which risks the device independence of the web; thus concerns: device-independence.
— https://github.com/WebKit/standards-positions/issues/68#issu...
Something isn’t a web standard just because Google decided to publish a specification. No other rendering engine has accepted these specifications.
> I don’t know why you keep glossing over this no matter how many times it has been politely pointed out to you.
I don’t believe anybody has ever said this to me before, let alone repeatedly, let alone politely, but perhaps I am forgetting. Could you refresh my memory? When did this happen?
[flagged]
[flagged]
[flagged]
And what else can drive priorities for software development in a company with virtually infinite resources?
Home Screen Safari and Browser Safari act very differently.
There are a lot of bugs where home screen safari passes feature detection but in reality does not work.
iOS and Safari are hell.
> 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?
The example that comes to my mind is apidock for Ruby!
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.)
I don’t see a problem with the github PR workflow for updating documentation. Yes, it’s one step more, but it’s nothing special when you use github’s online editor.
PS: MDN and MSDN are my favorite documentation sites.
MDN is on GitHub, every page ends with "View this page on GitHub • Report a problem with this content" links.
I've pointed out errors a couple of times and they were corrected pretty quickly.
I've found them responsive to errors too.
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.
Amazing game, with all that effort put in you definitely deserve some compensation for it. Have you considered uploading your game to itch.io and adding an option for players to tip you? Bonus points for not using any "gen ai" nonsense. And especially huge kudos for detailed hint system. Can't wait for your next game.
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?
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...
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.
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.
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.
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
You appear to be misinformed. OS-level features like IMEs and dictionaries work in WASM as they do with any native application. There is nothing special about HTML elements that enables them in a way that doesn't work with WASM; they are, after all, OS features, not HTML features, and the browser is just another native application. If somebody chooses not to integrate OS features in their application, that's a reason not to use their application, but it really has nothing to do with WASM in any way whatsoever.
> 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.
You appear to be mis-informed. Or maybe there's some mis-communication going on. WASM using HTML (ok, everything works), WASM using canvas doing all input and rendring (doesn't work). As just one simple example, the browser, in a textarea or input type=text can integrate with the OS's user dictionary for auto-correction. Your WASM app using draw to pixels can not, as reading the user's dictionary is a privacy violation. Similar issues exist for all of the other topics.
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
Don't you love how English can just turn your head around?
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.
> Browsers are designed to be the end user's self-service toolkit to combat our bad websites.
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?
Yeah, fifty reason why Web hasn't yet fully turned into ChromeOS Platform.
Standard Web in 2025 is whatever Google decides to implement on Chrome, and all existing forks downstream from it, including Electron crap.
How many times will we have to learn the same lesson? The web and web technologies suck as an app platform. Apple, Palm, Microsoft and RIM tried it.
I could probably give another 50 as could everyone else reading
Biggest peev for me is inconsistent support for transparent (alpha channel) video
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 seems more about Apple though?
Let Safari die already.
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.
To be fair, the macOS Safari is not tied to the OS. Don't remember if it ever was, but it def isn't anymore then.
Unfortunately it was and still is. https://en.wikipedia.org/wiki/Safari_(web_browser)#Version_c....
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.
It's absolutely amazing the degree to which Apple has recapitulated the Internet Explorer debacle of thirty years ago.
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.
> This game only works on browsers with reasonable compatibility
Just say Chrome. This is what you mean.
Nope, I do all my frontend dev for Firefox and then it works on Chrome too.
>TLDR: buy an old iPhone and test with it daily
>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.
iPhones tend to have dramatically better JavaScript performance so you might wanna also test on an average Android phone.
[dead]