An Abridged History of Safari Showstoppers

TL;DR: iOS Safari is more than an inconvenience for developers, it's the fundamental reason interoperability has been stymied in mobile ecosystems; frequent showstopping bugs, a large patch gap, and lack of competing engines ensures the web is not a credible competitor to native. Here are the receipts to prove it.

Last update: September 24, 2024.
Check out the Updates section to find out what changed.

As noted elsewhere, a developer-lamented but regulator-overlooked aspect of Apple's monopoly on iOS browser engines has been the prevalence of show-stopping bugs.

We define "showstoppers" here as bugs that cause working apps to become entirely broken or inadvisable to use on the web.

All browsers have issues, but iOS is unique in depriving users of choices that developers can recommend when the system-provided engine breaks. Users and developers have literally no choice; they can't choose a different browser to work around Apple's frequent bouts of platform breakage. How bad is it? To get a sense for the impact, we've laid out the worst issues of the past decade. We've also included a rough estimate of the fraction of time when web apps would have worked as advertised on iOS but for Apple's implementation… hiccups.

Before we get started...

Bugs in iOS Safari often affect every browser on the platform

It's important to keep in mind that all browsers on iOS are basically Safari. The Apple App Store Review Guidelines contain the following rule:

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.
Apple, App Review Guidelines

In practice, Section 2.5.6 is a requirement that iOS and iPadOS browsers from Google, Microsoft, Mozilla, Samsung, Opera cannot use their own engines the way they do everywhere else. [...] Competing browser vendors are only allowed to produce shells around a very specific, unaltered version of Safari's WebView; a component whose features Apple dictates.
Open Web Advocacy, Bringing Competition to Walled Gardens

This means that iOS Safari bugs generally affect every other iOS browser, and always impact PWAs installed to the iOS home screen. To make matters worse, despite announcing a mechanism intended to enable Safari and WebKit updates out-of-band from full OS updates, it is not used to quickly fix showstoppers. Apple tried to use it only once since 2022, immediately pulling the patch because it broke apps. In practice, Apple still requires slow and time consuming OS updates to deliver Safari fixes, delaying the rollout of patches for weeks, if not months.

Because all browsers on iOS have to use the specific build of WebKit that ships with the operating system, Apple has put itself in the unique position of being able to introduce bugs in every single browser on iOS with a push of a "roll out system update" button.

Did we miss anything?

Please reach out if you think we missed a bug that suddenly broke your website and we'll consider adding it to the list. Feedback is also very welcome. If you run into any inaccuracies, mistakes, etcetera, just send an email and we'll fix it.

inbox+webventures at rejh dot nl

Confidence Gaming

A good way to see how the combination of Apple's prohibition on competing browsers and its own underinvestment in Safari impacts users and developers is to ask "if someone were trying to build an app, could they use the web?". Organizations that bet on the web want to serve all users from a single, interoperable, portable codebase.

This means that Apple's forced monopoly makes iOS showstoppers a threat to the idea of investing in the web for reaching the world's wealthiest users. And what business or service can shrug off their flagship experience not working for the boss or board directors because they all have iPhones?

A thought experiment

In an earlier era, startups could build on the web and, if one browser didn't provide the features they needed, they could just recommend that their users try a better one. But that's not possible on iOS. So let's imagine two teams, struggling to build great experiences on the web: one is working on a social media app (ala Elk or Bluesky) and the other is building an image editing tool (e.g., Squoosh or Color.io or Figma or Canva).

Each of these tools needs a foundational set of features to work consistently and reliably in order for the idea of investing in the web to make sense: their PWAs have to compete against proprietary, platform-specific, non-interoperable native apps.

Social

Offline, Data Storage (IDB, Local Storage, Cache Storage), Smooth and Infinite Scroll, Media Recording and Playback, UI Components, Text Input, Push Notifications

Media

Offline, Data Storage, Media Recording and Playback, UI Components, Text Input, Web Assembly, Background Data Processing and Image Manipulation

Knowing what features are foundational over-and-above basic website functionality allows us to ask: could they bet on the web? Or put another way, given that all of these features have worked consistently across at least one other browser engine for the past 5 years, for what fraction of the past half decade would a well-written web app in each category have been able to compete with native apps?

Social PWAs

No modern social experience can compete without the use of Push Notifications. Apple only provided them for the web on iOS since March of last year, although it's unclear if anyone can consider them "supported" given the tragic state of Apple's implementation. But taking the most generous (to Apple) perspective, at least 3 of the 5 years we are looking at are a writeoff, starting with a failing score of 30%.

Naturally, any showstoppers introduced since then lower the score further.

From the list below, the most recent (as yet unfixed) showstopper appears to be breakage of on-screen keyboards in PWAs. It's unclear how a social app can work when users aren't able to type.

In total, the web on iOS has only been a semi-credible alternative to native apps for building social experiences for just 17 of the last 60 months, resulting in a flunking 28% score vs 95+% for Android, Windows, macOS, Linux, and ChromeOS.

Media PWAs

Media apps do not require Push, allowing us to consider more of the last half decade in our analysis. They do, however, require functional media playback (including in the background), as well as high-volume data storage via Local Storage, IndexedDB, and Cache Storage. Well-built media manipulation apps will also leverage Web Workers (and communication with them) as well as Offscreen Canvas for high-performance rendering. Media recording is necessary and Web Assembly is needed for implementing custom, high-performance media manipulation (including encoding for download).

Based on our data (see below), a well-built media app using these features will have appeared broken to iOS users for 35 of the last 60 months, meaning an ambitious media PWA would only be fully functional for iOS users 42% of the time across the past half decade.

Showstoppers by Year

Not every showstopper impacts every app, and many developers have been trying to build ambitious web experiences on iOS for much longer than 5 years. For completeness, here's a short catalogue of the worst issues impacting real-world apps.

2014: Completely broken IndexedDB implementation

Apple shipped IndexedDB with iOS 7.1 (March 2014) but it wasn't usable until iOS 10 (September 2016) due to "seriously buggy behavior as well as complete lack of support in WebViews".

Unfortunately, it seems as if Apple may have screwed up their implementation of IndexedDB - and screwed it up bad. Like real bad.
Raymond Camden, IndexedDB on iOS 8 - Broken Bad

Nolan Lawson kept a comprehensive list of the show-stopping issues that plagued WebKit's early IndexedDB implementation. In 2015, he summarized:

IndexedDB was proposed more than five years ago and has been available in IE, Firefox, and Chrome since 2012. Apple, on the other hand, didn't release IndexedDB until mid-2014, and when it did, it unveiled a bafflingly incompetent implementation that was so bad, it's been universally derided as unusable. (LocalForage, PouchDB, and YDN-DB, the major IndexedDB wrappers, all ignore Safari's version and fall back to WebSQL.)
Nolan Lawson, Safari is the new IE, 2015

Since WebKit happily reported IndexedDB was supported, any site that used feature detection broke. Developers were forced to fall back to things like UA sniffing in order to work around the issue.

Sadly, this wouldn't be the last time WebKit suddenly completely broke existing websites and later even leaked user data via their IndexedDB implementation.

Read more:

• Safari is the new IE
• Safari is the new IE 2: Revenge of the Linkbait
• IndexedDB on iOS 8 - Broken Bad

2015: 100vh (100% viewport height) means a different thing in mobile Safari to everywhere else

When working with Viewport Units there's this longstanding and extremely annoying bug in Safari on iOS where it does not play nice with the vh unit. Setting a container to 100vh for example will actually result in an element that's a wee bit too tall: MobileSafari ignores parts of its UI when calculating 100vh.
Apple/WebKit's stance is that it works as intended, although it's not what I (and many other developers) expect. As a result we have to rely on workarounds.
Bramus van Damme, 100vh in Safari on iOS

Later, Chrome and Firefox would reluctantly adopt the same behavior so all browsers would at least behave consistently. Attempts to reach out to WebKit and discuss better solutions were apparently ignored by WebKit.

Developers had to resort to workarounds, hacks and buggyfills to get Safari (and later Chrome and Firefox) to behave correctly. Eventually, Matt Smith came up with the pretty elegant -webkit-fill-available solution - but this didn't play nice with Chrome, requiring an extra @supports guard.

It wasn't until recently, when the svh, lvh and dvh units landed in all major browsers, that this issue was finally resolved. It's telling that it was not anyone on the Safari team who came up with a solution. They completely intentionally broke the 100vh unit, then ignored the issue for 4 years, and when an independent developer pitched (what would become) the new CSS units, it were the Chrome and Firefox teams who responded and put it on the agenda.

Read more:

• Viewport height is taller than the visible part of the document in some mobile browsers
• CSS: Watch out for 100vh height in mobile browsers
• Avoid 100vh On Mobile Web
• 100vh in Safari on iOS
• CSS fix for 100vh in mobile WebKit

2016: <body /> with overflow:hidden CSS is scrollable on iOS

The ability to block and/or control scrolling is essential for building advanced user interfaces like popups, bottom sheets, sidebar navigation, etcetera. This Interop proposal goes into more detail about the issue(s) and why they are important.

WebKit, especially on iOS, has had a long history of bugs related to (over)scrolling. Once more, web developers tried to hack their way around the issue, but these solutions were often brittle and never really completely solved the problem - or introduced some other limitation or unwanted behavior.

It took Apple 3 years to fix the initial bug but it didn't take long for someone to notice that they forgot to fix it for installed web apps. Instead of picking it up, WebKit requested that someone file a new bug for this case. Unfortunately, nobody did until 2020. Apple confirmed the new bug and added an internal radar link - and then, for 6 months, nothing happened (the ticket still has the status NEW). A new ticket was filed in 2021 which was eventually picked up. It took at least another year and 4 months to get fixed.

Even now, there are scenarios (240860, for example) where scrolling is not prevented when overflow: hidden is set on <body /> - so this bug is still not completely resolved.

Read more:

• Extend Scrolling to cover Body Scroll Issues

2017: Safari incorrectly blocks localhost as mixed content when accessed from an HTTPS page

According to spec, localhost should always be treated as Potentially Trustworthy. Chrome and Firefox (albeit reluctantly) behave correctly, but Safari does not:

Several popular desktop applications (e.g. Spotify) install a server that binds to a localhost port. The web application (e.g. spotify.com) then uses the localhost server to control the desktop application. In order to work around the mixed-content blocker, the web application connects over HTTPS to a host (e.g. *.spotilocal.com) that simply points to 127.0.0.1
...
This ugly hack suffers from a number of problems: it doesn't work when offline due to DNS resolution failure, it doesn't work through proxies, etc.
...
[ ...] the hack also requires a HTTPS certificate. This means that the private key of the certificate is embedded in the desktop application... (I hear some applications have even resorted to installing a root CA so that they can use a self-signed certificate...)
Birunthan Mohanathas , WebKit Bugzilla #171934 c8 and c9

2018: OS 11.2.2 broke WebAssembly

iOS 11.2.2 broke WebAssembly. This broke parts of Wikipedia, all existing published Construct content, and probably more. Much of the difficulty could have been averted by just turning off WebAssembly, so everything reverted to fallbacks. Instead they left it enabled but broken until the iOS 11.3 release months later. In the meantime Apple provided no meaningful help or support whatsoever. We only got support from a helpful Wikipedia engineer who shared a workaround they discovered.
Ashley Gullen, Safari releases are development hell

Although Apple fixed the issue within days, they took their time shipping it. They broke WebAssembly in 11.2.2, didn't ship the fix in either iOS 11.2.5 ¹ or 11.2.6, but opted to wait until iOS 11.3. Although there was a way to detect the bug and have some fallback, many existing websites that used proper feature detection were left broken for months.

2018: Safari 11.1 broke MessageChannels

Safari 11.1 broke MessageChannels in a way that broke Construct, and left us maintaining workarounds for years.
Ashley Gullen, Safari releases are development hell

The issue was reported in April 2018 and patched within days - but, again, Apple didn't prioritize shipping it. iOS 11.2, 11.3 and 11.4 came along without the fix. As far as we can tell, it finally shipped with iOS 12 in Sept 2018, almost 6 months later.

2019: Audio stops playing when standalone web app is no longer in foreground

With iOS 12.3, Apple completely broke background audio for installed web apps. It all worked fine in Safari and 3rd-party browsers on iOS, but as soon as you installed it as a web app, started playing audio and moved the web app to the background (either by switching to the home screen, another app or turning off the display), audio playback would simply stop.

It went unfixed for almost 3 years - and when Apple finally fixed it, they forgot to tell developers. There was no workaround except to prevent Safari from installing the web app.

Imagine if a company like Spotify would have believed Apple's claim that web apps are a viable alternative to native apps distributed through their App Store - their Music Player web app would have been completely, utterly useless without background audio! For three years!

2019: PWA in iOS uses old assets after publishing new servicerWorker/assets

We are currently using iOS 12.3.1 and the new changes in app/.js are [published], but the PWA in iOS load the old assets present in precache.
In Safari it works correctly, but when you're using PWA it does not work. There are behavioral differences between Safari and PWA on iOS.
Marlon Maxwel, Webkit Bugzilla

The PWA just needs to be [...] installed (added to the Homescreen).
Without the workarounds linked by others in the comments, this bug is a blocker to deploying a PWA on iOS.
Chris, WebKit Bugzilla

2020: Add Fullscreen API to iOS (& display fullscreen)

We realize that the Fullscreen API (FS API) on iOS is not so much broken as it is completely missing, but we decided to include it because it is absolutely critical for all but the most casual games. The fact that this API is not available on iPhones makes relying on the web to run these games completely infeasible on mobile. And even though the FS API is available on iPadOS, MDN reports that it's basically unusable for games:

Only available on iPad, not on iPhone. Shows an overlay button which can not be disabled. Swiping down exits fullscreen mode, making it unsuitable for some use cases like games.
MDN, Fullscreen API

In 2023, it looked like iOS Safari 17.2 was finally going to ship FS API support, but they pulled it before the final release due to too many bugs. It returned in 17.4 but as an experimental feature (off by default). 6 months later, iOS 18 (and 18.1 beta, for that matter) still requires users to manually toggle it on. But, hey, you might be excited that you can now use the FS API for <img /> on visionOS?! 💃

It's worth noting that the current (experimental) implementation on iOS has the same issues as what is available on iPadOS today. One has to wonder what use cases exist for fullscreen with a big overlay button, as the whole point of fullscreen is to hide system and browser UI. Or worse, imagine a game where every swipe will exit fullscreen mode (in the most distracting and annoying way possible). ¹

By the way, someone figured out that you could pipe a <canvas /> through WebGL and use that as a <video /> source (which does support fullscreen). It's telling how many hoops web developers are willing to jump through to get a fullscreen <canvas /> element. ²

The only alternative to the Fullscreen API would be to set display: fullscreen in the web manifest (and get users to install your web app). Sadly, iOS does not support that either. Fun fact: iOS may not support display: fullscreen, but matchMedia('(display: fullscreen)') returns true if you have it set (just to make sure feature detection won't work, I guess?). 🙃

2021: Safari shipped blob.stream(), crashes with a NULL pointer exception

Apple recently broke our website by adding support for a new API blob.stream() in Safari 14.1 (which we correctly feature-detected) but when you call the function you get a null pointer exception which crashes the renderer process. Worse, the bugs was fixed on master several months before Safari was released but it wasn't included in the release.
Feross Aboukhadijeh, Hacker News

Safari 14.1 shipped an implementation of blob.stream() that crashed the browser's rendering process. Developers who used proper feature detection woke up one morning to find their sites broken. The release notes made no mention of support for blob.stream(). Even if you did test with Safari Technology Preview releases, everything seemed to work just fine - until it didn't:

We did test in Safari Technology Preview, but it already had this fix applied so we didn't encounter the crash.
John Hiesey, WebKit Bugzilla

It's not clear which version of Safari landed the fix as the ticket was never updated.

2021: Appending an element to the shadow DOM in many cases hard crashes the browser process

WebKitGTK 2.32.0 is unable to load redhat.com, which somehow I didn't notice until now.
Michael Catanzaro, WebKit Bugzilla

Another case of "you can not rely on feature detection". If your site used web components, there was a good chance it would suddenly crash the browser process.

It's not entirely clear which iOS versions were affected, but given the timeline, we assume the fix landed in iOS 14.7 (July 2021).

2021: LocalStorage is broken when a page is open in more than one tab

This will result in data loss on websites, as two tabs will be writing to storage, unaware of each others' changes.
Additionally, the 'storage' event is used for cross-tab communication in Safari, since it doesn't support BroadcastChannel, and this bug breaks that.
Jake Archibald, WebKit BugZilla

The fix took a little over 2 months to land.

While this bug did not (directly) affect Safari on iOS and iPadOS, the workaround would: websites could switch to IndexedDB (which was unaffected) to prevent data loss, only to find it broken just a month later - again.

2021: IndexedDB APIs hangs indefinitely on initial page load

The first indexedDB.open() call made by a page appears to be flaky on first load in iOS 14.6.
Its readyState stays as "pending" forever, and none of the event handlers (including "onblocked") are called.
Simon Taylor, WebKit BugZilla

It's kind of baffling how this wasn't caught before it shipped:

Since this bug is so easy to trigger by just opening a database, it likely affects many other sites as well.
Feross Aboukhadijeh WebKit Bug Tracker

While there was a workaround, existing sites that relied on IndexedDB were broken until the fix was released in iOS 14.7 and macOS 11.5 about a month-and-a-half later.

Read more:

• Bad Apple Safari update breaks IndexedDB JavaScript API, upsets web apps

2021: Fetch request streaming is implemented just enough to pass feature detection, but it doesn't actually work

Safari half-shipped request streams in fetch, so it passes the feature detect, but doesn't actually support the feature.
Jake Archibald, Twitter

The bug ticket hasn't been updated since 2022, and web-platform-test reports that Safari is failing the test, so it looks like developers can still not rely on feature detection.

2021: IndexedDB API information leaks

[...] a software bug introduced in Safari 15's implementation of the IndexedDB API that lets any website track your internet activity and even reveal your identity
fingerprint.com, Exploiting IndexedDB API information leaks in Safari 15

This one was a biggie: Apple's Safari leaked IndexedDB data to other sites. Site isolation is the one thing that browsers are supposed to get right.

Apple did not respond to the bug for 6 weeks, at which point the security researchers who reported the issue felt compelled to disclose it publicly (and shame Apple into action):

The issue was reported to Apple on the 28th November 2021 but after 6 weeks of non-action was publicly disclosed a few days ago.
...
For iPhone and iPad users, the fix can not come too soon. While macOS users can and should use an alternate browser, on iOS all browsers use the Safari web engine, meaning all iPhone users have no mitigation except to stop using the browser on their phone.
mspoweruser.com, After ignoring it for 6 weeks, Apple starts testing fix for major Apple Safari privacy bug that leaks your Google ID

Safari 15.3 fixed the issue, which was released on January 26th 2022 - a patch gap of 60 days.

2023: Notifications API: support for the badge, icon, image and tag options

Safari 16.4 may have shipped full support for Web Push, but Apple's incomplete implementation of the Notifications API is basically unusable for anything more complex than websites that want to push "breaking news stories".

Back when iOS 16.4 launched, developers had to find out about these missing or incomplete features themselves, as the Browser Compatibility table on MDN had all but green checkboxes. More than a year later, features like badge, icon and image are still incorrectly listed as supported on MDN, and that's not entirely MDN's fault.

2024: On-screen keyboard does not show up for installed web apps (PWAs) when focusing a text input of any kind

After upgrading to iOS 18, I launched an installed web app (PWA / home-screen web app), tapped on an input field, and the on-screen keyboard did not show up as expected.
...
Our application is effectively broken on iOS 18, and this has a direct negative impact on our business as our customers cannot edit / write documents anymore.
...
So this is critically impacting our business every minute it remains unfixed.
John Ozbay, WebKit Bugzilla

Minor bugs by Year

While not every bug is a showstopper by itself, the web has suffered a lot from what can only be described as death by a thousand Safari bugs. If developers and users run into issues on sites at every turn, it drags down the entire platform. Accumulated, these issues become showstoppers.

We don't have detailed descriptions for each of them, but hopefully the sheer quantity of things that could break with any iOS release gives a good idea of what web developers have had to deal with over the years.

2008: Focus events for non-input elements behave differently in Safari to every other browser

Clicking on a button in Safari not only does not focus it but also removes focus from a previously-focused element. Instead of fixing this, Apple first spent more than a decade defending it (without testing it, presumably) and has now spent more than two years ignoring it after their theoretical claims about consistency were disproved.
All this while, websites that work everywhere else continue to break in Safari.
Mayank, When will Apple focus on Safari?

Note: WebKit may not actually be going completely off-spec here and they have done some related fixes/changes to improve the situation a bit. That said, I think most would agree that the current behaviour seriously hampers accessibility.

2012: Using border-image with border-style: none is rendered completely wrong

This one took 9 years.

2014: WebKit doesn't calculate padding-top/-bottom: n% correctly

2014: Pointer events should allow for device-pixel accuracy

This may be valuable on high-dpi devices. Eg. if scrolling is happening in physical pixel units, it should be possible to build JS applications that move things around just as smoothly (as is possible in native iOS apps).
Rick Byers, WebKit Bugzilla

The iPhone 4 introduced the Retina display in 2010, but the web on iOS still can't do device-pixel accurate interactions.

It took 10 years and Rick Byers (a Chrome engineer(!)) to update the testcase, but in Sept 2024, Apple finally started working on fixing this "oversight".

2017: Support for 120Hz requestAnimationFrame

It took years for this feature to land in Safari, but only for macOS (the 2021 M1 Macbook's introduced 120Hz displays). About a year later, it was reported that Safari on iPadOS shipped support for high frame rates (5 years after iPad Pro introduced ProMotion). iOS 18.0 dev beta 2 enabled support for iPhones, we assume this shipped with the final release of iOS 18.

However, high frame rates for the web are still disabled by default: users still have to manually disable the "Prefer Page Rendering Updates near 60fps"-option in Safari's feature flag settings (not a place that an average user will frequently visit).

[The option to cap frame rates at 60Hz in Safari] is default on for macOS, iOS, and iPadOS. Interestingly though, it is default off for visionOS.
Also I have another bug open that aims to change this. PWA apps run off of default feature flags, meaning changing the feature flag will not affect the PWAs. This means above 60fps is disabled for all PWAs.
Jeffrey Blanz, WebKit Bugzilla

As Blanz mentioned, PWAs still can not take advantage of this feature.

It's worth noting that native apps automatically run at high frame rates since iOS 11 (iPad Pro, 2017) and iOS 15 (iPhone 13 Pro, 2021).

2018: Some Fetch requests incorrectly completely skip the service worker

When using a FormData with file to send content of a form using the fetch API, the request doesn't go through the associated Service Worker.
nyro, WebKit Bugzilla

2020: Safari 14 shipped a broken replaceChildren() method, which caused glitches in Construct.

2020: When leaving current scope of PWA, back button incorrectly reads "Untitled"

Unfortunately, there is a bug, where the back button to your PWA shows "◀ Untitled" and not the actual PWA's name or short name
Maximiliano Firtman, iPhone 11, iPadOS and iOS 13 for PWAs and web development

The earliest bug report we could find is from 2020 but Maximiliano Firtman first wrote about it in his coverage of iOS 13, which was released the year before. We reached out to Firtman and he said he did try to bring this to the attention of the WebKit team after writing the article.

Apple, meanwhile, has marked the WebKit bug as INVALID (but were kind enough to create an internal ticket for it which was then ignored for more than 2 years):

I believe the issue is occurring outside of WebKit. Apple internal see rdar://54220296
Smoley, WebKit Bugzilla

It was fixed in one of the minor iOS 16.x updates (somewhere between 2022 and 2023).

2020: Safe-area-inset-bottom still set when keyboard appears

2020: Support for background-attachment: local has suddenly completely disappeared

2021: IntersectionObserver and ResizeObserver fire in incorrect order

The linked ticket is from 2022, but I first ran into this issue in Feb 2021. I think this is how it shipped in Safari 13.1 (2020). I never filed a ticket because I found a ticket that seemed related (which is still not (completely) resolved btw): #196729
Roderick Gadellaa, for this blog

iOS 16.4 included the fix.

2021: Mousemove events fire when modifier keys are pressed, even if the mouse isn't moved

Huh, this is an interesting one. Safari fires a mousemove event on keydown/up if the key is shift, ctrl, alt, cmd etc, even if the mouse hasn't actually moved.
Neither Chrome or Firefox do this. Safari doesn't do it for other keys.
Jake Archibald, Twitter

In Safari's defence, the MouseEvent objects have boolean properties for the state of those keys, so it's kinda sort-of reasonable to fire another event when that state changes.
But yeah, firing mousemove when the mouse didn't move feels weird.
Jake Archibald, Twitter

2021: Scrolling in home screen apps incorrectly latches to document

As WebKit's Simon Fraser summarized:

UIKit has a bug where, if an ancestor scroll view is rubber banding, you have to wait for it to stop before you can scroll the inner scroll view (tracked internally).
Simon Fraser, WebKit BugZilla

This bug completely broke scrolling for a few seconds whenever the user overscrolled within any child element (including the one the user just scrolled).

2022: WebM Opus support is inconsistent in Safari

On Safari 15.4 on iPadOS 15.4, WebM Opus playback is not detected with canPlayType(), does not play with <audio>, but it does actually work if passed to decodeAudioData.
Ashley Gullen, WebKit Bugzilla

[...] it's unclear if Apple are even working on it, with no clear indication about their intentions since I filed that issue around a year ago.
Ashley Gullen, Safari releases are development hell

2022: Installed web app with viewport-fit cover causes overscroll issues, breaks position fixed and -webkit-fill-available

The overscroll issue was fixed in iOS 16.3, but the ticket was never updated (or assigned to anyone). The other issues that were mentioned in the ticket(s) have not been fixed as of this writing.

2023: iPadOS: Viewport doesn't correctly restore after dismissing software keyboard for installed web apps

2023: iPadOS: window loses focus when dismissing the keyboard, breaks Page Lifecycle API

2024: Svh and lvh are incorrect on iOS in third party browsers

Updates

The following changes were made to this post since it was published:

September 24, 2024

• New: 2020: Add Fullscreen API to iOS (& display fullscreen)
• New: 2021: Safari shipped blob.stream(), crashes with a NULL pointer exception
• Thanks: Open Web Advocacy

Thanks!

• Alex Russell for help in drafting and edits 💖
• Open Web Advocacy for their tireless work to bring browser competition to iOS (and everywhere else).

References

• "PouchDB 3.0.6: Safari Madness", 2014
• "IndexedDB on iOS 8 - Broken Bad", 2014
• "Safari is the new IE", 2015
• "Safari is the new IE 2: Revenge of the Linkbait"
• "Safari is the new Internet Explorer", 2018
• "Bad Apple Safari update breaks IndexedDB JavaScript API, upsets web apps", 2021
• "Safari isn't protecting the web, it's killing it", 2021
• "Progress Delayed Is Progress Denied", 2021
• "Safari releases are development hell", 2023