AAPL Stock: 117.81 ( -0.22 )

Printed from

Apple hiding Safari code from developers

updated 10:55 am EST, Fri February 29, 2008

Apple hides Safari code

A Firefox developer who goes by the name Vladimir said on his blog that Mac OS X could potentially have code that enhance Safari's performance. In his blog, Vladimir says that while collecting feedback from Mac beta testers for Firefox 3, several have indicated that the new iteration seems to be anywhere from 50- to 500-percent slower than v2.x. After some troubleshooting, Vladimir reveals that the screen drawing synchronicity engine causes the issue.

Called "coalesced updates", the Mac OS uses this to synchronize all screen drawing done at the OS level. Vladimir notes that an Apple tech document reveals a way to exclude an application from the update cycle, which in turn enhances the performance of the application.

When he went to inspect WebKit - the developer version of Safari - he noticed that it was able to draw much quicker than Firefox, going beyond 60 frames per second, over double that of the coalesced screen drawing. WebKit, however, did not feature the exemption code. This means that there is an unknown factor which links Safari to be very close with the Mac OS, and that Apple wants to keep this information hidden.

Vladimir says that WebKit is now host to "over 100 'OS-secrets-only-WebKit-Knows' in the library". Despite these claims, Vladimir says that he does not insinuate that Apple is trying to be malicious in any way

"To be clear, I do not think that Apple is in any way trying to purposely "cripple" non-Apple software," says Vladimir. "I also do not think that undocumented APIs give Safari any kind of "significant performance advantage" (as Firefox 3 should show!). However, as I said, the undocumented functionality could be useful for Firefox and other apps to implement things in an simpler (and potentially more efficient) manner. I don't think this is malicious, it's just an unfortunate cutting of corners that is way too easy for a company that's not fully open to do."

Earlier this month, Computerworld's Seth Weintraub noted that Safari was due for a large speed boost, based on his experiences with the current build of WebKit.

by MacNN Staff



  1. njfuzzy

    Joined: Dec 1969



    As far as I can tell, the proof of this is "I can't see any other reason, so this must be it!" That's hardly solid.

  1. godrifle

    Joined: Dec 1969


    Now if only...

    ...Apple would use their secret weapon code to improve Java performance, we'd be set!

  1. Seedublyew

    Joined: Dec 1969


    Read before you Report

    Perhaps the writer of this post should have read the entire thread before posting to have more of a balanced, less sensational post. David Hyatt (who I believe is heading up development of WebKit/Safari and might now a thing or two about the APIs) Posted what seems to be the official response to this discovery. He points out that there were publicly documented and more importantly, supported methods of achieving the same result discovered by Vladimir, and that the WebKit team is able to implement these APIs as a form of development to bug hunt and ensure that the API's are matured and therefore not a moving target for developers, before they are published.

  1. analogika

    Joined: Dec 1969


    Not "Hiding" Not "Secret"

    There is nothing "hidden" or "secret" in an OPEN-SOURCE LIBRARY!

    Everything is documented in the code (and yes, it's there in the comments, apparently - according to the slashdot thread on this subject).

    In fact, the "hidden code" affecting screen redrawing IS NOT EVEN USED BY SAFARI - IT's TURNED OFF! (It's a hack that's only there to ensure that THIRD-PARTY APPS don't break.)

    This story is complete rubbish - in fact, it indicates the OPPOSITE of what the title implies:

    "Apple using private WebKit code to fix broken third-party apps"

  1. mudmonkey

    Joined: Dec 1969



    MacNN, this is plainly bad reporting. The issue has been discussed and closed, but you fail to mention David Hyatt's response.

    The final line: "Earlier this month, Computerworld's Seth Weintraub noted that Safari was due for a large speed boost, based on his experiences with the current build of WebKit" is the kicker. Seth's look at the WebKit builds is in no way linked to the story about stubbed placeholder code, and to suggest a link is rather disingenuous.

  1. petsounds

    Joined: Dec 1969


    tabloid reporting

    This issue was already resolved long before MacNN decided to druge it up and use the story for shock value (ad revenue $$). MacNN's reporting is getting worse and worse, to the point that I'm about ready to find my news elsewhere.

  1. dogzilla

    Joined: Dec 1969



    Seriously, stop propagating BS. Take the time to understand wtf you're talking about before posting an article so you don't perpetuate what is clearly BS. If you don't understand the technical details of what's going on, find someone who does. Lacking all that, at least take the time to fully read the article, comments and responses. Had you read TFA and the responses on /. or the original post, you would have found a response from the Webkit developers which pretty clearly debunks the poster's whining. If you can't comprehend what the Webkit dev is saying, then please refrain from posting the article because (sorry) you ain't qualified to have an opinion or pass the info on, since you're just going to s**** things up.

  1. ZinkDifferent

    Joined: Dec 1969



    Maybe if they had mentioned that the lead developer of Safari replied to Vladimir and explained, in detail, what is going on, then, maybe, this would count as news.

  1. adrian_milliner

    Joined: Dec 1969



    ... it must be nice for webkit authors to have firefox authors publicly worry about the competition.

  1. ViktorCode

    Joined: Dec 1969


    my 2 cents

    David Hyatt has it explained, and in my opinion as a professional developer and code-quality reviewer is this: the drawing code in computational intensive app should account for the fact that FPS is capped, either by technical constraints or by human eye perception. I hope the next composition engine for FireFox 3 (which will be implemented in next beta, according to Vlad) will hold to this standard, and will effectively use time to next frame instead of just stalling critical computation.

Login Here

Not a member of the MacNN forums? Register now for free.


Network Headlines

Follow us on Facebook


Most Popular


Recent Reviews

Ultimate Ears Megaboom Bluetooth Speaker

Ultimate Ears (now owned by Logitech) has found great success in the marketplace with its "Boom" series of Bluetooth speakers, a mod ...

Kinivo URBN Premium Bluetooth Headphones

We love music, and we're willing to bet that you do, too. If you're like us, you probably spend a good portion of your time wearing ...

Jamstik+ MIDI Controller

For a long time the MIDI world has been dominated by keyboard-inspired controllers. Times are changing however, and we are slowly star ...


Most Commented