Apple announced and shipped the official Safari 4 release on the first day of WWDC. This was preceded by an extensive beta period, where Mac and Windows users could download the new version and test their websites and web applications with the new Webkit engine included with Safari 4.
Apple received a lot of useful feedback in terms of bugreports and also regarding the user interface changes the beta included ((Customer uproar notably lead to a reversal of the decision to place Safari’s tabs at the top of the browser window.)).
However Apple and website developers aren’t the only stakeholders with an interest in any new version of Safari: Many OS X and iPhone applications rely on Safari’s Webkit underpinnings, e.g. to display web content or generate HTML previews directly within an app. Safari provides the default system-wide Webkit framework, so any update to the browser will also affect those applications reliant on Webkit.
As expected with any major update, many 3rd party apps and plugins required updates to deal with the changes introduced by the Safari 4 beta. This is par for the course and most users expected a few glitches – it was a beta, after all.
But when the final Safari 4 release was announced at the WWDC keynote, it was quite different than the beta versions that preceded it. Cosmetic changes aside, a number of changes had also been made under the hood: The final release (which was automatically distributed to all OS X 10.4 and 10.5 users via Software Update) used Webkit version 530.17 – a notable jump compared to the Safari 4 beta releases, which used Webkit versions 528.16 & 528.17.
It’s understandable that Apple would want to include all the bugfixes and improvements the Webkit team added as a result of the beta, but it is a bit disappointing that 3rd party developers weren’t given a chance to test those changes in the shape of a release candidate. As a result, a number of applications, websites and web applications needed to be re-tested with the final Safari 4 release and as usual, some of these required minor updates to restore compatibility with Safari 4 ((Apparently, even the iPhoto team hadn’t been able to thoroughly test 4.0: Safari 4.0.1 was released to specifically address compatibility issues with iPhoto’s Facebook integration & Places feature.)).
Webkit has become such a crucial OS X framework that releasing an update without extensive testing seems careless. To release such a large update on the first day of your own development conference, which developers spend a lot of money to attend, seems downright callous ((And releasing a browser that crashes when customers visit your online store, on the day you release a bunch of new products seems – well, just plain stupid.)). It effectively means that any testing and possible bugfix releases are delayed by at least a week, after developers have returned home from WWDC (and sobered up).
Is this a big of a deal as I’m making it out to be? Probably not: In the grand scheme of things, I’m guessing most developers and users couldn’t care less. But Apple does a much better job in this respect with other products, giving developers ample time and opportunity to thoroughly test their apps against most major iPhone and OS X updates before they’re released. Let’s hope a similar strategy can be adopted for Safari in future as well.
Adrian Kingsley-Hughes at ZDNet has also written a post outlining a number of Safari 4 issues. More indication that the final release was slightly rushed?