While Apple and Google had long worked together on the open-source WebKit project for years, developers both inside and outside of Google wanted Google to move away from Apple. In addition, the two tech giants had different visions for the Web browser engine.
As Adam Barth, a Google Software Engineer wrote:
Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation — so today, we are introducing Blink, a new open-source rendering engine based on WebKit.
This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines — similar to having multiple browsers — will spur innovation and over time improve the health of the entire open web ecosystem. In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files — comprising more than 4.5 million lines — right off the bat. Over the long term, a healthier codebase leads to more stability and fewer bugs.
Throughout this transition, we'll collaborate closely with other browser vendors to move the Web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we've set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency.
Justin Schuh, a Google Chrome security software engineer, added on Google+ that while he's not speaking for Google or the Chromium project, that:
I think it’s safe to say that the Chrome security team has taken a very active role in WebKit security over the last several years, and really led the pack in making Webkit more robust against exploits. We’ve fuzzed at previously unheard of scales, paid out hundreds of thousands of dollars in bug bounties, performed extensive code auditing, fixed many hundreds of security bugs, and introduced a slew of hardening measures. And while we're very proud of the work we've done on WebKit security, the fact is that it’s getting harder and harder for us to make a big impact anymore.
The big issue is a side effect of Chrome’s design. While our architecture has tremendous strengths (beyond just security), it’s also very different from other WebKit-based browsers, and grows even more so with the rest of the WebKit project's increasing focus on the WebKit2 layer. These differences have forced us to make increasingly difficult decisions, like sidelining major security enhancements that don’t fit well with WebKit. Meanwhile, we were regularly handling security regressions resulting from things like differing release schedules, and maintaining legacy behavior required by WebKit as an API [Application Programming Interface]. These growing pains are common enough when a project like WebKit evolves to encompass such a broad set of consumers, but eventually you can reach a point where the burden on some members is just too high.
So, with the Blink project we now have a chance to fix quite a bit of technical security debt that’s accumulated over the years. These changes are all things that fit well with Chrome’s architecture, but were not viable in WebKit given their impact on other platforms.
These security issues have often been mentioned as a reason for Google to leave Apple behind. In some Web developer circles it's been felt that Apple's programmers hadn't been carrying their fair share of the load of making WebKit (which Apple's Safari Web browser uses) secure.