As you’re probably aware, Apple recently released an update to Safari, bringing it to version 2.0.1 (for those running 10.4) or 1.3.9 (for 10.3.x users). But what you may not know is that this isn’t actually the most current version of Safari. Earlier this year, Apple officially open sourced a technology known as WebKit. As described by Apple on the WebKit Open Source Project Page, WebKit is…
…the system framework used on Mac OS X by Safari, Dashboard, Mail.app, and many other OS X applications. It is based on the KHTML engine from KDE.
What this means is that the code that Safari uses to actually draw web pages is now publicly available to anyone. Developers can look at the code, fix bugs, even suggest (and implement) new features, and submit those changes back to the project for inclusion in future versions of the WebKit. Why should you, if you’re not a developer, care about this open source project? Because it lets you run a version of Safari that’s even newer than the one you just updated a couple days ago. This means you can get bug fixes and new features long before they’re released as part of a normal software update.
As an example of why that might be beneficial, consider the following image:
These are two screenshots of something known as the Acid2 Browser Test. It’s a test that helps browser developers insure that their products meet defined web standards. The ideal results are quite simple—a smiling face on a yellow background. Getting to those results, however, involves the browser successfully handling CSS, HTML, PNG, and something known as Data URLs, which is a way of embedding small data items within HTML code. In the above screenshot, the image at left shows you how Safari 2.0.1 renders the smiling face; on the right are the results as seen when using the open source Web Kit version of Safari. Clearly, the open source version is doing a much better job at the test than is the current OS X version.
There are other advantages as well—the current version of WebKit allows the styling of form elements. Form elements are things like radio buttons, checkboxes, OK buttons, etc. In Safari, these objects all get the Aqua look-and-feel, which is something that annoys most web designers—the Aqua look may not match the design of the pages they’re creating. Safari, when run with the open source WebKit, now allows these elements to be styled to match the page, as can be done in most every other browser.
It’s not all peaches and cream, though. This page lists some of the things that won’t work in the WebKit version of Safari when compared to the “real” version. In addition, you may build a version that’s buggy and unstable (though I’ve been lucky so far, and haven’t had any such problems). You really are testing leading edge versions of the code when you build your own version of WebKit. Thankfully, the “standard” Safari with the stock WebKit continues to work just fine, and can even be used at the same time as Safari with the open source version of WebKit.
Installing the Web Kit version of Safari isn’t necessarily complicated, but there are some prerequisites. First, you must have installed Xcode 2.1, as explained in my first Geeky Friday blog entry. Second, you must be running 10.4—sorry, but you can’t build your own Safari for earlier versions of OS X. Finally, you should be at least somewhat comfortable typing commands in the Terminal (though you don’t need any real Unix knowledge to succeed).
Note: If you’d like the easiest way possible to get the open source WebKit version of Safari installed on your machine, your best bet is a program called NightShift, ( VersionTracker page, MacUpdate page ) which will automatically download and install the latest version of WebKit on your Mac. Read on if you’d like to see how to do it yourself…
The quickest “hands-on” way to build the open source WebKit is to follow Apple’s instructions for both getting the code and building the code. My instructions that follow are just those instructions, with lots of added explanations to help those with less experience.
The first step is to make a folder (Shift-⌘-N) that will hold the WebKit files. It’s important that the full path to this folder does not contain any spaces. As such, I recommend creating a folder in your user’s folder somewhere—in my case, I created a folder named “builds” (which is a term that describes the process of compiling code) at the top level of my user’s folder (alonside Documents, Pictures, etc.). You can place this folder wherever you like; just make sure there are no spaces in the names of any of the folders along its path.
After creating the folder, launch Xcode (in /Developer/Applications) and select Xcode: Preferences. Click on the Building icon in the toolbar, and then click Customized location in the “Place Build Products in” section of that panel. Click the Choose button, and navigate to the new folder you just created, then click the Choose button to select that folder. When you’re done, it should look something like this (with your path and folder, not mine, obviously):
Once this is done, you can quit Xcode and open Terminal; it’s time to go get the WebKit code. Please note that, unless otherwise specified, each of the following commands should be followed by a press of the Return key. The first thing to do is make sure you’re in the directory you created for the files, so type cd /path/to/folder/to/use. In my case, that command was cd ~/builds. The WebKit files are stored in something known as a concurrent versioning system, or CVS. A CVS makes it easy for many people to work on the same pieces of code at the same time. To use something in a CVS, you need to check it out. First, in case you’ve never accessed a CVS before, type touch ~/.cvspass. You only need to do this once; it just avoids some problems you may have if you’ve never used CVS before.
Next, it’s time to login to Apple’s CVS machine, with this command:
cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root login
You’ll be prompted for a password; just enter anonymous and press Return. Nothing will appear to happen, other than the appearance of the Terminal prompt. But you’re now connected to Apple’s WebKit CVS. The next step is to “check out” (download) a set of tools that makes working with WebKit much easier. Enter this command:
cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root co -P WebKitTools
You’ll see some commands go streaming by, and when done, you’ll again be back at the password prompt. Now that you have the WebKit tools, you can use them to grab the actual WebKit code from the CVS. Enter this command:
WebKitTools/checkout
This step may take a while, depending on the speed of your connection. Lots and lots of messages will scroll by on the screen, indicating which files are being downloaded to your machine. When it’s all done, the last message you see should look like this:
=============================================================== Web Kit sources are now checked out and ready to build. You can build by projects in Xcode or with the build-webkit script. The build-webkit script is inside WebKitTools/Scripts along with other useful scripts; it's a good idea to put that directory into your shell's search path. ===============================================================
Here’s a short movie [2.2MB], showing exactly how these first commands look when entered into the Terminal—this may help make the steps a bit clearer.
You only have perform this long checkout download one time. In the future, if you wish to update to newer versions of WebKit (there are usually changes made on a daily basis), you can use one command from your builds directory:
WebKitTools/Scripts/update-webkit
This will grab the latest updates to the code (you’ll need to re-build Safari again after doing this; see below). Now that you have all the code needed to build the open source version of WebKit, the final step is to do just that, with this command:
WebKitTools/Scripts/build-webkit
The amount of time it takes to build WebKit will vary based on the speed of your machine. On a Dual 2.0GHz G5, it took about six minutes (with a bunch of other applications running). On a PowerBook G4 1.33Ghz, with nearly nothing else running, it took more like 17 minutes. In other words, go and have a cup of coffee, work some crossword puzzles, play a game, browse the web. Do anything other than stare at the Terminal screen, waiting for the build to finish. Eventually, it will finish…
When the build eventually does finish, you should see this message:
=========================================================== Web Kit is now built. To run Safari with this newly-built code, use the run-safari script. ===========================================================
As an aside, note that you’ll have to re-build WebKit each time you use the update-webkit command—in other word, you use update-webkit to get the new parts, and then build-webkit to put those parts together into a finished product.
Now you probably want to load up your new version of Safari. First, just to be safe, make sure your “real” version of Safari isn’t running, then type:
WebKitTools/Scripts/run-safari
Again, this is from within your builds directory (as that’s where the WebKitTools directory lives). When you hit Return, you’ll see a couple of messages in the Terminal, and then Safari will open. You can check out the
Acid2 test page to see the new and improved smile, and play around with some of the other new features (mainly of interest to web site designers). When you’re done, just quit the “new Safari” with ⌘-Q as you would any other normal application. To run it again in the future, open a Terminal, cd into your builds directory, and use the above run-safari command.
Apple’s WebKit pages are a great place to start for more info on the WebKit project. In addition to the links already provided, there’s an active wiki with tons of info in it, a blog page that updates the progress being made with WebKit, and you can even search for all open WebKit bugs if you’d like to see what the current issues are. Having WebKit available as an open source project means that you can, relatively easily, keep your version of Safari current with all the features and bug fixes that Apple is constantly making to the program.
This article was modified, based on feedback from ‘armadillo,’ to include information on the NightShift program and to correct some technical errors in the description of what precisely WebKit is…