Why wouldn't Apple document performance-boosting APIs?

Vladimir Vukićević from Mozilla's Firefox team eventually managed to turn Firefox 3 into a speed demon on Mac OS X. But Apple sure didn't help with the process.

Apple may not have been trying to cripple non-Apple applications on Mac OS X, but the fact that it's not open source means that the world is beholden to Apple's whims, as Vlad writes:

I do not think that Apple is in any way trying to purposely "cripple" non-Apple software. 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.

Apple benefits the better that all applications run on Mac OS X, not just Apple-developed applications. Throttling performance - wittingly or unwittingly - is not in its interest. Open source would resolve the issue in Apple's favor.

[StargateFan]

Frankly I would not put it past Apple to do something like this. This goes back to business, everybody thinks the tactics Microsoft use are bad when doing business. Which yes, they are pretty bad in most scenarios, but at the end of the day the objective is still the same, get our product out by any means possible, or simply defined as today's business. I am not condoning these actions, and I truly believe that it has become a standard in today's business and certainly needs to change.

Of course apple will benefit from any and all developers which code fore their platform it boosts their sales. But at the same time Apple's biggest developer is Apple. It goes back to the hardware and OS operation. Build the Computer and give them the OS too, for more profit. Now give the the hardware the OS and the software which runs significantly better then outside developers and we create a halo effect equaling more profit for us.

This can potentially be bad for Apple, if they continue to do so it is theoretical that their products will take such a large precedent over any outside developers that they could create a monopoly inside their own monopoly, and those developers will leave the platform. Which of course will not have an immediate impact on Apple, until they of course make a mistake with the software, which every developer does, think of the initial reviews of iMovie 08.

But the bottom line is this, everyone believes Apple to be a kind and caring company that they can always trust. While Microsoft is this totalitarianism based company waiting to destroy anything, which in some cases is true. But at the end of the day both companies are the same and have the same goal. Apple is no different than Microsoft.

[flyermoney]

Matt, do your homework, please. As widely reported on teh internets, on day one of Vladimir's post, David Hyatt, main Safari developer at Apple, responded to the issue in the comments:

"The programmatic disabling of coalesced updates should not be public API. It?s actually a very dangerous thing to do. We aren?t really happy with that code in WebKit, but we had to do it to avoid performance regressions in apps that embedded WebKit. Technically it?s wrong though, since we turn off the coalesced updates for any app that uses WebKit! This includes drawing they do that doesn?t even use WebKit.

As for the window display throttling, that was a pref designed for Safari (that we don?t even use any more). It?s not private or magic. It?s nothing more than a pref that we can examine from Safari-land, so linking to that is just silly. ;)

Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can?t be depended on, or they are part of something inside a framework that may not be fully formed. WebKit subclasses several private NSView methods for example, and it cost us many many man hours to deal with the regressions caused by the internal changes that were made to NSViews in Leopard.

As you yourself blogged, there was a totally acceptable public way of doing what you needed to do.

For any private methods we use that we think should be public, we (the WebKit team) file bugs on the appropriate system components. Many of these methods have become public over time (CG stuff in Leopard for example). Be careful when you dig into WebKit code, since we may continue to use the WK method even though it?s not public API just because we need to work on Tiger."