A New Year's call to Apple: publish and be damned
Mac Secrets Please don't imagine that writing for El Reg is a piece of cake, much less a sizable rum-soaked hunk of Stollen with most of the marzipan in it.
Like war, writing can be hell. The ink was barely dry on my first Mac Secrets column in March 2008, when I got a rather hostile email from a Mac fanboi, telling me that I would go to hell in a hand basket because I was proposing to naughtily reveal all sorts of undocumented secrets relating to the Apple Cocoa APIs.
The gist of his argument was that foolish young developers might read my column, be lead astray by incorporating undocumented API calls into commercial software, and then find themselves up the creek without a canoe when Apple released a new version of OS X.
For sure, there's something to be said for this argument. My correspondent pointed to all the problems that Unsanity experienced in trying to port their stuff from Tiger to Leopard.
Even now, with many people using Snow Leopard, there's been relatively little movement towards Leopard-compatibility, let alone its successor. On Unsanity's website, read Jason's blog entry Hiya Kid's It's Theming Time and then see the following two months of increasingly disappointed whinges from customers demanding an SL-compatible upgrade. Doesn't look good.
So was my anonymous correspondent right? Well, that all depends on whether or not the Unsanity folks used undocumented calls in the implementation of their Application Enhancer (APE) technology. I can't really say, because I've never peeked seriously at the APE code but, if so, this might well explain their present difficulties. That would especially be the case if those undocumented routines don't exist in a 64-bit callable form, because 64-bit operation is the default modus operandi under Snow Leopard.
Now, I have written a couple of plugins for Safari, and I actually found it pretty straightforward to get the code working, both for 32-bit and 64-bit code. Rather than using invasive plug-in managers such as SIMBL, PlugSuit, APE, or the now defunct Input Manager mechanism (no longer supported for 64-bit processes), I simply made use of the DYLD_INSERT_LIBRARIES mechanism to get my bundle loaded by Safari. For another Snow Leopard compatible approach, used by 1Password, click here.
The bottom line is that it's generally possible to find ways to inject plug-in code into specific processes, rather than using techniques that can potentially screw up every running process, either maliciously, or - more likely - through unintentional bugs.
But, getting back to undocumented calls. Another thing my correspondent pointed out was that if an API call was undocumented, it was because Apple weren't ready to document it. This is an argument that I found singularly unconvincing. It suggests, amongst other things, that the undocumented code Apple uses is immature. If true, it would make perfect sense not to document it. But the fact is that Apple routinely use undocumented methods, classes and whole frameworks that have been around for years. If these things were part of the published API, then wouldn't this make everyone more productive?
In the days when I wrote Windows applications for a living with Borland Delphi, it was great having access to the complete VCL frameworks source code. Anytime you came across a weird bug, you could step right through the framework code until the problem became apparent.
This is something that Cocoa developers can't do. In recent times, even Microsoft have seen the light, releasing the source code to their .NET frameworks with the comment that doing so will "enable developers to build better applications and make even better use of them." Presumably, "them" refers to the frameworks in question.
So how about it, Apple? While making your New-Year resolutions, here are a few to chew on:
- Make the source code of the Cocoa frameworks available. At the very least, this should include AppKit and Foundation. Developers will love you for it.
- Stop using undocumented API's in application code. Microsoft did it and got hammered for it. You only get away with it because of all the fanbois around. Stop it. Eat your own dog food.
- Above all, remember that your developers are your friends. Yes, even when they're submitting software for review and inclusion on AppStore. (That one's for Rogue Amoeba).
Have a Happy Holidays and a great New Year. ®
Apple vs Microsoft
"Stop using undocumented API's in application code. Microsoft did it and got hammered for it. You only get away with it because of all the fanbois around."
No, Apple get away with it because they're not sufficiently dominant in the market.
A documented API is considered by Apple to be like a contract. By documenting it, they are promising that they will try their hardest not to change it in any incompatible way in the future, and any deviation from this would be considered a bug (and, depending on the impact, a showstopper).
There are lots of reasons why an undocumented API may remain in that state. Often it’s because the API as it currently exists only works properly in a limited subset of the scenarios which the parameters suggest it might. Or it might be that it’s a poor fit with the rest of the API in a given area. Or it’s because the developers intend to change it in the not hugely distant future.
Apple regularly opens up its private APIs once they release maturity if there’s a solid case for doing so, and did precisely this when Snow Leopard was released (Quick Look, for example, moved from PrivateFrameworks to being part of QuartzCore with the arrival of 10.6).
As the old adage goes… don’t make a promise you can’t keep.
bad for business
Apple is just learning from the Microsoft camp. Microsoft successfully killed off dozens of potential competitors for its sub-standard suite of applications, all by using undocumented APIs to give it an advantage over those competitors.
If the fanbois would just realize that they're defending a Microsoft strategy, and would stop enabling Apple from doing the same thing, we'd get further ahead. Instead, I'm hearing a lot of excuses from these waffle-brained idiots (a group I was once part of, much to my embarrassment) who refuse to think long term or refuse to realize that constructive criticism really is the core of improvement.