Frontend · JavaScript · Programmer

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

By ErpanOmer · Aug 18, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

A single WebKit bug breaks every browser on every iPhone worldwide because Apple mandates its engine on iOS. Teams shipping web apps to mobile users cannot treat Safari as an edge case; they must budget for engine-specific hacks that no AI code generator will produce correctly.

Summary

WebKit's lag on key APIs like Web Push, PWA installation, and WebRTC is not an engineering failure. Apple deliberately keeps Safari just capable enough to browse but never good enough to replace native apps, protecting the App Store's 30% cut. On iOS, every browser—Chrome, Firefox, Edge—is forced to use WebKit underneath, so a single engine bug affects over a billion devices with no escape hatch.

Frontend teams pay the price in concrete, recurring breakage: `100vh` miscalculates viewport height by including the toolbar, the `Date` constructor rejects space-separated timestamps, `overflow: hidden` on body is ignored by the rubber-band scroll effect, and the notch forces exclusive `safe-area-inset` variables. The CSS standard added `dvh`, `svh`, and `lvh` units specifically to patch Safari's viewport behavior.

Nearly 20% of global browser traffic runs on WebKit, and the share is higher among iOS users in China. The EU's Digital Markets Act is pushing Apple to allow third-party engines in Europe, but the restriction remains locked down in mainland China as of 2026.

Takeaways

— Apple's 30% App Store commission creates a business incentive to prevent Safari from becoming a full native-app replacement.

— On iOS, Chrome, Firefox, and Edge are all forced to use the WebKit rendering engine, so one engine bug hits every browser on the platform.

— Web Push took 8 years to arrive on iOS, and PWA installation and WebRTC implementations remain incomplete or buggy.

— `100vh` in mobile Safari includes the address bar and toolbar in its calculation, causing content to hide behind the browser chrome.

— Safari's `Date` parser requires a `T` separator between date and time; a space-separated string returns `Invalid Date`.

— Setting `overflow: hidden` on `body` does not prevent scrolling in Safari because the rubber-band bounce effect overrides the CSS declaration.

— The iPhone notch and Home Indicator require handling `env(safe-area-inset-*)` variables that exist only in Safari.

— CSS units `dvh`, `svh`, and `lvh` were added to the standard specifically to work around Safari's viewport-height behavior.

— Nearly 20% of global browser traffic uses WebKit, and the proportion is higher among iOS users in China.

— The EU DMA is pushing Apple to allow third-party browser engines in Europe, but the restriction remains in mainland China as of 2026.

Conclusions

Safari's bugs are not random quality issues; they form a pattern of strategic neglect concentrated on APIs that narrow the gap between web and native apps.

The forced WebKit monopoly on iOS means Apple's engine decisions are not just a Safari problem—they are a platform-wide constraint that no competing browser can bypass.

The creation of `dvh`, `svh`, and `lvh` in the CSS spec is a rare case where a single vendor's implementation forced the entire standards body to add workaround units.

AI code generators trained on Chrome-dominated datasets will systematically miss Safari-specific breakage, making experienced frontend judgment harder to automate than it appears.

Concepts & terms

WebKit

The browser engine developed by Apple that powers Safari and, by mandate, all other browsers on iOS. It handles HTML parsing, CSS layout, and JavaScript execution.

dvh / svh / lvh

CSS viewport-height units added to the standard to fix Safari's `100vh` behavior: `dvh` is dynamic viewport height, `svh` is the smallest possible viewport height, and `lvh` is the largest possible viewport height.

safe-area-inset

Environment variables in Safari (`env(safe-area-inset-top)`, etc.) that define the area of the screen not obscured by the notch, rounded corners, or Home Indicator on iPhones.

PWA (Progressive Web App)

A web application that uses modern browser APIs to behave like a native app, including offline support, push notifications, and home-screen installation. Safari's limited PWA support restricts these capabilities on iOS.

From the discussion

The conversation centers on concrete, recurring Safari bugs that make front-end development painful. A detailed list of high-frequency pitfalls—viewport units, fixed positioning, date parsing, and syntax support—is offered alongside practical workarounds. A separate point flags a specific layout inconsistency where em-based positioning fails in Safari while working correctly in other browsers.

— Safari's rendering bugs are so numerous that developing for iOS provokes constant frustration.

— The visible complexity of front-end work is underestimated, particularly by backend developers.

— Using 100vh in iOS Safari is broken because it includes the address bar height; dvh or JavaScript fallbacks are necessary.

— position:fixed elements misbehave when the on-screen keyboard appears; switching to absolute positioning with transforms is a more reliable pattern on iOS.

— Date string parsing is brittle in older Safari versions, where dash-separated dates produce Invalid Date; a library like dayjs should be used instead of native parsing.

— New JavaScript and CSS features must be checked against Safari's support on caniuse before production use.

— Teams should maintain a formal Safari-specific pitfall checklist integrated into code reviews to catch issues early.

— Using em units for left/top positioning produces incorrect results in Safari, unlike in Chrome and Firefox.

Featured comments

咬代码的兽

The pitfalls in Safari are endless. Here are a few high-frequency minefields to add: ① 100vh in iOS Safari includes the address bar height; use dvh or a JS fallback. ② position:fixed goes completely off when the keyboard pops up; on iOS, try switching to an absolute+transform approach. ③ Date parsing is format-sensitive; dash-format dates in old Safari directly result in Invalid Date. Use dayjs uniformly, don't write raw code. ④ For new syntax, check its Safari support on caniuse before pushing to production. It's recommended that the team maintains a Safari pitfall checklist in the code review checklist—it saves way more time than firefighting afterwards.

ErpanOmer

Thanks [heart hands]

沫丶汐

I feel this deeply. Safari is called the new-age IE. For positioning properties like left and top, when using em as the unit, Chrome and Firefox display in the correct position, but Safari doesn't.

ErpanOmer

Yes, this issue is worth discussing.

See top comments, translated →

Source: juejin.cn ↗ Google Translate ↗ Backup ↗