Safari's WebKit Bugs Are a Business Model, Not a Mistake

After nearly a decade of coding, I've experienced countless blood-pressure-spiking production incidents. But if you ask me which bug is the most despair-inducing, it's not memory leaks or request race conditions. It's that classic line that makes every frontend engineer's pupils dilate:

It works fine on Chrome, but it's broken on Safari😖.

You've tuned everything on Chrome. The layout is perfect, animations are smooth, and APIs are working. You confidently submit your code, even patting your chest in the group chat saying: self-testing passed.

Then QA walks over with an iPhone and shoves the screen in your face expressionlessly. You see a layout mess you've never seen before, or a white-screen crash that's completely unreproducible in Chrome DevTools.

This isn't your code's fault. It's Safari, or more precisely, the WebKit engine, messing with you🫵.

---

This isn't a bug; it's Apple's business choice

Many people attribute Safari's various bizarre behaviors to the browser development team's lack of skill. This is a huge misunderstanding. The WebKit team's engineers are absolutely world-class, but the problem is: their priority has never been making Web applications better.

You must understand Apple's business logic. What is Apple's core profit model? It's the 30% cut from the App Store. For every app listed on the App Store, every transaction generates nearly a third of its profit for Apple.

And what are Web applications? They are alternatives that bypass the App Store. If browsers were powerful enough to run complex applications perfectly, why would developers still pay to list on the App Store? Why would users still download native apps?

Therefore, Apple has an extremely strong business incentive to make Safari's Web capabilities just good enough, but never good enough🤷‍♂️.

You'll notice an incredibly strange pattern: for almost every key API that could bring Web apps closer to a native experience, Safari is always the last to support it, and the support is always bumpy. Web Push took a full 8 years to be barely supported on iOS; PWA (Progressive Web App) installation experience is still incomplete; WebRTC implementation is full of exclusive compatibility landmines.

---

On iPhone, every browser is Safari

If Safari's problems only existed within Safari itself, you could just tell users to switch browsers. But Apple did something even more domineering: on iOS, whether you download Chrome, Firefox, or Edge, their underlying rendering engines are all forcibly replaced with WebKit.

That's right, the Chrome you open on an iPhone is just Safari wearing a Google skin. All rendering, all JavaScript execution, all CSS parsing goes through the WebKit pipeline.

What does this mean? It means when WebKit has a bug, all browsers on over a billion iPhones worldwide will be hit simultaneously, with no exceptions. Your users have absolutely no escape route.

Although the EU's Digital Markets Act (DMA) is pushing Apple to open up third-party engines in Europe, in the Chinese mainland market, this blockade remains ironclad in 2026 😖

---

Those classic Safari pitfalls that collectively break frontend developers

Having covered the macro-level reasons, let's dig into some of the most classic, most maddening Safari-exclusive bugs. If you're a frontend developer, you've definitely experienced at least three of the following scenarios👇.

The 100vh problem

This is probably the most cursed Safari bug in frontend history.

On Chrome, 100vh is exactly 100% of the viewport height, clear and simple. But on mobile Safari, the calculation of 100vh actually includes the bottom address bar and toolbar. When the user scrolls and the address bar auto-hides, the actual visible height of the page and the value of 100vh become misaligned.

The direct consequence: your carefully designed full-screen landing page will always have a portion of content obscured by the bottom toolbar on an iPhone, preventing users from seeing your core button.

This problem tormented frontend developers worldwide for years, until the CSS standard was forced to add three new units: dvh (dynamic viewport height), svh (smallest viewport height), and lvh (largest viewport height). And the birth of these three patch units was entirely because of Safari alone🤷‍♂️.

The Date constructor

A single line of code that runs perfectly on any browser in the world, but on Safari directly returns Invalid Date:

// Works perfectly on Chrome, Firefox, Edge
new Date('2026-08-17 15:30:00');
// Output: Mon Aug 17 2026 15:30:00

// On Safari: directly crashes
new Date('2026-08-17 15:30:00');
// Output: Invalid Date

The reason is absurd: Safari's Date parser strictly requires a T separator between the date and time (i.e., 2026-08-17T15:30:00) and does not accept a space. This is an incredibly tiny format difference, but it's enough to completely paralyze your entire time display module on all Apple devices.

The failure of overflow: hidden

When you set overflow: hidden on the body in Safari to prevent page scrolling (like locking the background when a modal opens), you'll find the page can still be dragged. This is because Safari has an incredibly stubborn rubber-band bounce effect that directly ignores your CSS declaration at the underlying level.

To solve this, frontend developers are forced to use JavaScript to listen for touchmove events and forcibly prevent default behavior, even needing to dynamically toggle position: fixed on the body—something that could be solved with CSS is forced into an extremely ugly JS hack on Safari.

Safe Area Inset and the notch

Since the iPhone X introduced the notch and the bottom Home Indicator bar, Safari has had an exclusive set of env(safe-area-inset-*) environment variables. If your page doesn't handle these safe areas correctly, your bottom navigation bar will overlap with the Home Indicator, and users simply can't tap the lowest buttons.

This set of things doesn't exist on any other browser; it's a pure frontend adaptation cost forced by Apple's hardware design.

---

Your users won't change just because you hate Safari

Complaints aside, Safari's market share is what it is. Nearly 20% of global browser traffic comes from WebKit, and this proportion is even higher among domestic iOS users. You can't abandon these users, so you must learn to compromise within WebKit.

Safari's problems are fundamentally not technical issues, but products of business gamesmanship. As long as Apple's App Store commission model remains unchanged, WebKit's strategic delay of cutting-edge Web APIs will not stop.

But then again, it's precisely because of an extremely hostile host environment like Safari that the frontend engineer role cannot be easily replaced. AI can generate a set of code that runs perfectly on Chrome, but it absolutely cannot write the kind of code that only an old-school frontend developer who has been tortured by Safari countless times can produce🫡.

Alright, that's all for today's sharing🙌