I have many MANY grievances with Safari:

1. Mandating all browsers on iOS/iPadOS to be powered by Safari (excluding in the EU). This doesn't sound bad, but wait until #3 below...

2. Safari's many bugs. Too many bugs. Oh so many bugs. Damn that's a lot of bugs.

- See: https://webventures.rejh.nl/blog/2024/history-of-safari-show...

- Also see the State of CSS developer survey where Safari makes up such a large portion of pain reports that "Safari" is its own category: https://2025.stateofcss.com/en-US/usage/#css_general_pain_po...

- And again in the State of JS developer survey: https://2025.stateofjs.com/en-US/features/#browser_apis_pain...

3. Grievance 1 and 2 compound together. Whenever Safari (or a Safari update) breaks a feature, you cannot inform a user that they can use another browser as a work around (because all browser engines are forced to use Webkit on iOS/iPadOS)

4. Bad dev tools. This has been seeing much needed improvements (e.g. being able to type an entire word in the css pane instead of a new character on each line), but it still feels 7 years behind.

5. No way to report bugs. There is a "bug reporter" at bugs.webkit.org, however each bug is auto-tagged with a link to an internal bug tracker within Apple. This means that those who are trying to fix bugs and those are trying to report bugs have a wall between them. There is no way to have a discussion to try to narrow down what the bug is, why the bug happens in one case but not another, what's really the cause of the issue, or why the bug matters more than whoever is assigned it might realise. When reporting a bug to Apple, it's more useful to talk to an actual wall because it might fall on you giving you an actual response.

6. Performing incorrectly is more important than getting the performing correctly. This one takes some explanation, but it's a little tricky. I'll give three examples then show how they're all the same issue:

Example 1: The cool homepage.

I was working on a website. Two months before launch I decided to spend a month of time juicing up the homepage, then one more month on polish.

On the homepage I decided to use the brand's pre-existing graphics and turning them into a parallax animation (inspired by: https://www.firewatchgame.com/)

It had:

- Regular content on the page

- Parallax layers with simple vector graphics inside them so that when the user scrolled down the page, the user saw a parallax animation of the landscape changing. (e.g. far clouds, far mountains, close clouds, close mountains, hill, foreground, simple bubble particles closer than the regular content on the sides to strengthen the depth of field illusion, etc...)

- Other vector graphics following a motion path animation

- This was done in 2017, so before CSS got scroll driven animation support, or motion-path support. It was also done without JS.

- Everything worked brilliantly, until we discovered that one particular iPhone model rendered an empty blank white page.

- I lost the last month trying pulling the effect apart trying to diagnose the bug (and with Safari's buggy dev tools being no help I had to do it in the dark). I was able to determine when the bug would trigger, and had to tear down my whole homepage and rebuild it with 2 fewer parallax layers before launch and 3 days of polish for the rest of the website before launch.

(you can see the final result at https://myobrace.com, but I really would have liked the extra time for polish, if you're wondering how I achieved the effects without JS and/or scroll-driven animations, I used css's perspective and transform rules to position the elements back in the z-axis then scaled them up so they appeared the correct size with the regular page content so as the page scrolled, the elements further back appeared to scroll at a different speed. I then used SMIL for the motion paths in the SVG elements).

Example 2. The texture

I wanted to add a repeating texture to buttons so they didn't feel so flat without needing a separate network request to download an image.

I tried generating one with SVG but the SVG 1.1 filter effects implementations aren't all hardware accelerated.

I tried generating one with CSS which worked everywhere but Safari.

You can see a texture here where the texture is generated entirely within CSS, and it doesn't work in Safari (but I didn't hide the seams because the result looks like a cool mosaic and I wanted to share the technique): https://codepen.io/spartanatreyu/pen/Yzbmvbr

(if you're curious about the actual texture I used, I hand drew a minimal noise texture in photoshop that could be repeated without showing seams, then base64 encoded it and inlined it within the CSS file so it could be loaded without needing an extra network request. You can see my development version here: https://codepen.io/spartanatreyu/pen/YzoexGg?editors=1100 (the final version is locked behind a login wall in a child-friendly education webapp))

Example 3. Asset downloading

I made a webapp for kiosk machines that downloads 100mb+ of video assets when logging in for the first time. iPads have a kiosk mode so I supported iPadOS' Safari mode so that the iPads could be used in commercial settings as kiosk machines.

When the final assets were added, the iPad machines would randomly crash during the asset downloading process.

With Safari's completely broken debugging experience, I eventually learned that as Safari downloads a video, as soon as it tries to put that downloaded data somewhere, it has to copy it across to the new place it's being stored, and if you're copying more than 3mb, it crashes the browser.

The fix was to download and store each video in 1mb chunks. This slowed down the installation speed by a bit over 300%, but at least Safari didn't crash any more.

---

Now back to: "Performing incorrectly is more important than getting the performing correctly."

It turns out Safari on iOS/iPadOS has an invisible time/performance budget. Anytime Safari hits that budget, the browser stops what its doing.

- Drawing texture to screen? How about we stop drawing all textures to the screen, including text. Websites don't need to draw any text right?

- Rendering a texture in CSS? How about you have the color white covering everything else instead.

- Downloading a video that's more than 3mb? How about I crash the browser when the download completes.

Compare this to Firefox and Chrome, as they run out of their budget, they stop starting new work so they old work can finish before starting their next task. The page may take a few milliseconds longer to get to the correct result on slower devices, but the result IS correct.

Even worse:

- Safari has no way of informing the code how close it is to the budget.

- The budget can only be found by trial and error.

- If the iOS/iPadOS device has other apps in the background, the budget is smaller.

- Each device has a different budget, so you have to penalize all Safari devices to the smallest supported budget of the oldest supported device.

- If you hit the budget on the most basic functionality (e.g. a homepage, a button, downloading required assets), then your website / webapp may as well not exist to those Apple users.