Ten years ago, Apple CEO Steve Jobs surprised the Internet world by unveiling Safari, a new desktop Web browser. Apple’s goal was to provide a fast and simple, yet first-rate, Web browsing experience for the Macintosh. Apple has since added new features, but amongst Mac browsers Safari has always had an edge for behaving like a Mac app – and often leading the pack for sheer performance.
Still, for many Web users Safari is an also-ran. It was never more than a distant third to to Internet Explorer and Firefox, and then a distant fourth with the ascendence of Google Chrome.
Safari’s biggest impact over the last ten years isn’t reflected in usage statistics; rather, it’s in WebKit. WebKit is software that displays Web content. Apple created WebKit for Safari, but now it’s everywhere, including Google Chrome, Android devices, and almost everything Apple. Through WebKit, Safari has played an enormous role moving mobile devices away from the lame Wireless Application Protocol (WAP)-driven “mobile Web” to making smartphones and tablets full-fledged – and soon to be dominant – players on the “real” Web. As weird as it sounds, if you’ve used the Internet from a smartphone or tablet, you probably have Safari to thank.
How did that happen?
The Olde IE Days
Safari got its start back in 2001. Apple was shipping Internet Explorer as the default Web browser in Mac OS (Yes young one, there was once a Mac version of IE) but when Steve Jobs returned to Apple in 1997, he worked out a complex patent-sharing and settlement agreement with Microsoft. One part made Internet Explorer the Mac’s default browser for five years.
The so-called browser wars between Netscape and Internet Explorer were in full swing. Microsoft’s deal with Apple was a victory for Redmond, but was also a long-term problem for Apple. The Internet was becoming a big reason people used computers, and Apple believed the Web was only going to become more important. The five-year agreement meant Apple was ceding a central aspect of the Mac experience to Microsoft. Microsoft didn’t own the Internet, but was infamous for its “embrace, extend, and extinguish” strategy to competitors. (That strategy had helped kill Cyberdog, an earlier Apple browser.)
Then, as now, Apple preferred to control its own destiny, designing the Mac experience from the hardware on up. Switching to someone else’s browser in five years could just be an exercise in choosing a lesser evil, so Apple began work on its own Web browser long before the Microsoft agreement ended.
“I don’t remember a deadline at first,” wrote a former Safari engineer who didn’t want to be identified, “but [Safari] was moving fast and by summer [of 2002] the team was aware of that date.”
As soon as the agreement expired, Apple unveiled Safari and had a free beta ready to download. By June 2003, Safari hit version 1.0 and Internet Explorer for Mac was history; by October, Safari was the Mac’s default browser.
The Fork In The Road
The core of a Web browser is a layout engine, software that interprets the content of a Web site and works out how to display it on screen. For Safari, Apple could have made its own layout engine with whiz-bang Mac-only features, but according to managers at Apple at the time, Apple wanted its Web browser to make Macs the best way to access the Web, and that meant not by creating cool Mac-only capabilities they hoped Web sites would adopt. A standards-based, open-source layout engine was the way to go.
The obvious candidate was Gecko, originally developed for Netscape Navigator. Gecko had improved performance and standards support for Netscape, and Apple could have used it: Gecko was released as open source in 1998, so it was powering not just Netscape, but also browsers like Galeon, Chimera, the nascent Firefox (then called Phoenix) and the Mac-only browser Camino.
However, when Apple unveiled Safari it also revealed Safari was built around the lesser-known KHTML layout engine from Konqueror, developed by the KDE community. Apple spun off its own version of KHTML to make its own layout engine, which it called WebKit (known in development circles as “forking”). Don Melton, the original engineering lead on Safari, noted Apple chose KTHML over alternatives like Gecko due to its standards support, clean design, and small size. Still, the choice caught the Internet community off guard.
“KHTML may have been a bigger surprise than Apple doing a browser at all,” Melton wrote in his blog recalling Jobs’ public announcement of Safari. “And that moment was glorious. We had punk’d the entire crowd.”
Not everybody was pleased. Apple had been making changes to KHTML (and the KJS Javascript engine) in secret for a year or more. Apple honored open source commitments and began releasing its work back to KDE — that’s a crucial point, because it meant Apple didn’t own WebKit and anybody could build on Apple’s contributions. However, the sheer volume of material (and choice of tracking systems) made integrating Apple’s work daunting, and some questioned whether it should be done at all.
“KHTML devs were excited and wary,” wrote one KDE developer who now works on WebKit-based software but didn’t want to be named. “Apple’s move validated KHTML and their resources could seriously advance [KHTML and KJS]. But nobody wanted Apple stepping in and taking over KHTML as its own.”
It took more than two years for things to settle, with Apple only open-sourcing its entire KHTML fork in mid-2005. The rift echoes today: despite efforts to merge, KHTML is still separate, and still the default layout engine in Konqueror.
Nevertheless: WebKit was out of the gate and available as open source … and the Internet hasn’t been the same.
Going Mobile
Apple uses WebKit in Safari and its own apps like Mail, but other desktop software uses WebKit too, including Adobe’s AIR and Creative Suite, plus Google Chrome — and Chrome is far more popular than Safari. In a bit of a role reversal, Microsoft uses WebKit in Outlook for Mac, and in Entourage before that.
That’s significant support, but WebKit’s real impact has been on mobile platforms. Believe it or not, Nokia was the first phone maker to jump on WebKit, building a WebKit-based browser for its S60 phones. It was arguably the first “real” browser for a mobile device: most phones slogged through the WAP-enabled “mobile Web,” while S60 phones were successfully accessing the same content as desktop browsers. The S60 browser lifted the veil, proving that putting a real Web browser in a phone was not only possible, it was vastly better than stripped down mobile-only sites – or sites that didn’t work at all on phones.
WebKit truly came into the mobile spotlight in 2007 with the iPhone. Not only did the iPhone access the same Web as desktop computers, Mobile Safari was originally the only way to make iPhone software. Apple quickly reversed course and moved toward native iPhone apps, but in 2009 Palm’s webOS made a daring move and bet everything on WebKit: webOS’s whole interface is driven by WebKit.
“When webOS came out, I was excited because its native apps are written in Web technologies: HTML, JavaScript, and CSS,” said former Palm human interface developer Tomomi Imura, via email. “Mobile Web apps were finally being treated as a first class citizen, and WebKit made it happen.”
WebKit Everywhere
Palm’s webOS was a commercial failure, and Palm’s former software director Paul Mercer blamed WebKit for not performing like native apps. But webOS’s unfortunate trajectory didn’t harm WebKit.
Right now, WebKit dominates mobile Internet. Figures from NetMarketShare have WebKit-based browsers accounting for over 85 percent of the mobile market. On the desktop, WebKit is mostly represented by Safari and Chrome; according to StatCounter, that’s almost 45 percent of the desktop browser market, although NetMarketShare tallies up a more conservative 23 percent.
Who are all these WebKit users? To start with, they’re the hundreds of millions of people using iPhones, iPod touches, and iPads. Need hundreds of millions more? WebKit is also at the heart of Android. Since the first devices went on sale in 2008, the Android browser has been based on WebKit. As of BlackBerry 6, the Playbook and BlackBerry smartphones use WebKit; so does Samsung’s bada mobile operating system, Amazon’s cloud-assisted Silk browser for Kindle Fire tablets, and even the experimental browser Amazon puts in recent Kindle ereaders. Browse the Web on a Nintendo 3DS? It uses WebKit. The upcoming Tizen mobile OS is making a bet like webOS: Tizen is Linux under the hood, but the interface is powered by WebKit.
Out in the real world, WebKit has helped make the Web experience consistent. Up until a few years ago, it wasn’t unusual to find major sites that only worked in Internet Explorer, didn’t work in Safari, or were totally inaccessible on a phone. Now, Internet users expect most Web sites will work regardless of the browser or device they’re using. WebKit is not solely responsible, but it’s been a huge factor – and it’s reaping the rewards.
“WebKit is the face of the mobile Web today,” wrote the former Safari engineer. “I don’t think anyone imagined that when Safari shipped.”
History, Doomed to Repeat Itself?
WebKit has a down side. WebKit’s success on mobile devices means apps and sites sometimes rely on features that aren’t part of HTML5 technology – not yet, anyway. Examples include ways to support high-resolution “Retina” images, along with gradients, transitions, shadows, transformations, and font effects. Some of the niftiest Web sites and Web apps for mobile look (and work) best only in WebKit browsers.
“So many mobile Web sites are only optimized for WebKit,” noted Tomomi Imura. “Microsoft’s, Opera’s, and Mozilla’s developer evangelists are working hard to advocate their platform and educate developers, but this is a side effect of WebKit being the defacto standard.”
Many Web technologies (from simple ones like Do Not Track to complicated ones like HTML) are defined by the World Wide Web Consortium (W3C). Interested people (but mostly companies) join working groups and try to hammer out a free standard everyone can use. The process is usually slow, so once a proposal begins to solidify both commercial and open source projects often jump on early versions as an experiment … or to get an edge on competitors. W3C standards may not be formally completed for years after a technology becomes commonplace.
WebKit’s dominance means other layout engines face a difficult choice: wait for tomorrow’s standards, or support WebKit’s stuff today? Opera has already moved to emulate WebKit; FireFox is strongly considering it, and Microsoft aped WebKit briefly in Windows Phone 7 then reversed itself. For years, desktop browsers had little choice but to be compatible with Internet Explorer, because its dominance meant most websites were designed with IE in mind. Now, mobile browsers face similar choices about WebKit. It’s an eerie echo of the battles between Internet Explorer and Netscape.
Patents also complicate W3C standards. Apple’s iOS handles touch events – taps, pinches, swipes, and gestures – in its own code, but Apple’s model was implemented separately by others and came into WebKit from Android in 2009. The W3C standards process got started, and (of course) WebKit browsers started using touch events right away. But in 2011 Apple disclosed patents covering touch events (including U.S. patent 7,812,828, part of Apple’s fight with Samsung and Motorola). Those patents may not stand up, but the W3C’s process to standardize touch events stopped dead. Microsoft has submitted its own (quite different) Pointer Events as a possible replacement, but the dust hasn’t settled
What A Long Strange Trip It’s Been…
Ten years after Apple introduced Safari, it still hasn’t taken over the desktop browser market, or even made a major dent. It probably never will. Nonetheless, by forking KHTML and birthing WebKit, Safari’s influence has been at least as important to the modern Web as Internet Explorer and Netscape’s most-famous progeny, Gecko and Firefox. It’s a testament to the broad reach of open source technology… and and something to think about when you fire up your mobile browser.
