Private API and Open Source
It’s hard for me to get past the absurdity of Apple’s position here. It’s simply baffling why one of the largest open-source projects they sponsor--WebKit--violates platform protocols by using private API’s, and apps directly bundling such code can’t be deployed on the platform’s major distribution channel, the Mac App Store. Wouldn’t it be better for Apple to open up these private API’s, make them public, and allow third-party developers to use them if necessary? WebKit’s use of these API’s dates back to the earliest days of the project; I found commit messages from 2002 that report their inclusion. Tk would certainly benefit if use of those API’s could be made legal. If a platform vendor’s private API is used in a vendor-sponsored open-source project, how truly private is the API? If Apple is going to be consistent here, shouldn’t WebKit remove these private API calls, and find another way to render browser windows in a smooth, crisp fashion?
In a way, it does make sense. Other core OS projects that Apple has open-sourced also use private API—that probably should stay private. But I agree that it would be nice to be able to ship a customized version of WebKit. And if a Web browser needs private API to get good performance, that’s probably also a code smell.
1 Comment RSS · Twitter
It’s been a while, so I don’t have specific references and won’t be able to find them now, but there were a number of instances where someone at Mozilla figured out how Safari did something key to being a performant modern web browser, discovered it was done via a private API, and hyatt commented in the Mozilla bug that the Mozilla folks should file a Radar to get the API Safari used made public.
Also, way back in 2008 during the “disabling coalesced updates” issue (which you wrote about here), hyatt commented [Wayback Machine] and noted that the WebKit team did file Radars to get some of the private methods WebKit uses made public.
So inside WebKit there is (or was) at least an awareness of the problem and a willingness to address it in some fashion, but given where we are today, it’s also clear that it is not (enough of) a priority for WebKit or for Apple management.
