Subscribe to
NSLog(); Header Image

WebKit vs. Safari

John Gruber writes up a method for invoking the same AppleScript on Safari and WebKit. That's all well and good, but it reminds me of one of my annoyances.

You see, I wouldn't mind running WebKit nightly builds, but I don't want to run Safari and WebKit at the same time.

It'd be nice if you could download WebKit nightly builds named "Safari" - or change the name after download easily - and run that.

I haven't tested it, but it may be worth while. I could run a cron-launched AppleScript that:

  1. Quit "Safari".
  2. Downloaded the WebKit nightly build.
  3. Renamed "Safari" to "Safari (Orig)" or something ((WebKit doesn't had full nibs or resources - so you'd need to keep Safari around so WebKit could run - see the first comment.)).
  4. Renamed the WebKit nightly to "Safari" and moved it to /Applications.
  5. Launched "Safari" and chose the "Reopen All Windows From Last Session" item in the "History" menu.

That would work, wouldn't it? The app would be known as Safari, scripts would work, applications that know Safari handles URLs by default would keep working, and life would be grand.


2 Responses to "WebKit vs. Safari"

  1. Since the WebKit nightly relies on starting your copy of Safari and telling it to use the new frameworks in the WebKit bundle, I don't think actually deleting Safari would be a good idea.

  2. I routinely have both WebKit Nightly and Safari open at the same time. The reason is that I use WebViews within Cocoa apps I'm developing, and to see exactly how HTML/CSS will render within a WebView, I've got to view it in normal Safari and not WebKit Nightly. Then, my normal browsing is done in WebKit.

    If everyone just used the nightly build of WebKit I think the web would be a lot nicer place 🙂