Why Google Forked WebKit into Blink While Apple Kept WebKit

In 2013, Google made the monumental decision to fork the open-source WebKit rendering engine to create Blink, the engine that now powers Google Chrome and other Chromium-based browsers. Meanwhile, Apple chose to stay the course and continue developing WebKit for its Safari browser. This split occurred primarily due to conflicting multi-process architectures, increasing codebase complexity, and a mutual desire by both tech giants to accelerate their respective paces of innovation without hindering the other.

The Conflict Over Multi-Process Architecture

When Google launched Chrome in 2008, it used Apple’s WebKit engine to render web pages. However, Chrome introduced a unique multi-process architecture that isolated each browser tab into its own sandboxed process. This prevented a single crashing tab from taking down the entire browser and improved security.

Years later, Apple decided WebKit also needed a multi-process framework and introduced "WebKit2." Because Google had already built its own custom multi-process system on top of the original WebKit, Chrome could not easily adopt WebKit2 without a massive rewrite. Consequently, the WebKit codebase had to support two completely different ways of handling processes, creating friction between Google and Apple engineers.

Different JavaScript Engines

Another point of divergence was how the two companies handled JavaScript. Apple used its native JavaScriptCore engine within WebKit. Google, wanting faster performance for complex web applications, built and used its own engine called V8.

Maintaining compatibility for both JavaScriptCore and V8 within the single WebKit project required complex abstraction layers. This added unnecessary bulk to the code and created extra work for developers on both sides whenever they wanted to make core changes.

Slowing Pace of Innovation

Because Chrome had a uniquely different underlying architecture compared to Safari and other WebKit browsers, engineers had to spend a significant amount of time ensuring their updates did not break the other company's browser.

A change made by Google for Chrome’s benefit could accidentally break Safari, and vice versa. Reviewing code, debating architectural direction, and maintaining backward compatibility slowed down the development process for both companies.

To solve these issues, Google forked WebKit in April 2013 to create Blink. By taking a copy of the WebKit code and striking out on its own, Google achieved immediate benefits:

  • Code Reduction: Google was able to immediately delete roughly 4.5 million lines of WebKit code that existed solely to support Apple’s architecture and other non-Chrome platforms.
  • Architectural Freedom: Google could now make deep structural changes to the rendering engine to improve speed and security without needing approval from Apple.
  • Out-of-Process Iframes: The fork allowed Google to easily implement features like out-of-process iframes, which vastly improved Chrome's security model.

Why Apple Stayed with WebKit

While Google needed an engine tailored for the sprawling, cross-platform ecosystem of Chrome, Apple had different priorities that made sticking with WebKit the logical choice.

  • Hardware Optimization: Apple designs both the hardware and software for macOS and iOS. Continuing with WebKit allowed Apple to tightly integrate the engine with its own chips, focusing heavily on battery life, energy efficiency, and smooth rendering on Apple devices.
  • System Integration: WebKit is not just the engine for Safari; it is a core framework of iOS and macOS. Thousands of third-party apps rely on the system's WebKit framework to display web content. Abandoning or drastically altering it would break app compatibility across Apple's ecosystem.
  • Clean Slate Without Google: Just as Google benefited from removing Apple-specific code, Apple benefited from Google's departure. Apple engineers were able to strip out all of Chrome’s custom hooks and V8 compatibility layers, leaving WebKit leaner, faster, and fully aligned with the WebKit2 architecture.

Ultimately, the split was a necessary evolution. The fork freed both Google and Apple from the burden of compromise, allowing Blink to evolve for cross-platform speed and web application dominance, while WebKit evolved for power efficiency and deep integration within the Apple ecosystem.