A New Year's call to Apple: publish and be damned
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 …
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.
And one that I, personally, was bitten by when developing for the original 512K Mac, is that Apple, in their finite wisdom, may decide to yank the code to keep others' apps from competing with Apple-written code.
Back in the day, I worked on a project that planned to use the Mac SDK's CoreEdit package (full-function text editing with fonts and styles, basically equivalent to MacWrite) to implement text markup in a networked writing-lab system. Came the day we tried to link those libraries into our test app, the headers and libraries were all missing, though they were still listed in the SDK documentation. Apple bluntly told us they'd yanked the libraries for competitive reasons, and we had to devise crummy workarounds.
With this in mind, it doesn't take much imagination to tconclude that Apple might well hold a few cards up its sleeve in the form of perfectly functional but undocumented APIs.
Undocumented methods may be excluded from general use because the code is an ugly hack or really is liable to be changed in a future product. It may be at a point where you really are not meant to interface non-original program code into the system.
As you say, however, applications - as in separate commercial product - ought not to use undocumented calls. Now with stuff that is part of your distro, that's okay.
Just wondering - what's the female equiv of fanboi. fangurl? Maybe that's a pointless q as it doesn't exist. Then again...
"Have a Happy Holidays and a great New Year."
Right back at you - have a good one!
And it's not just Apple & MS doing it either. I haven't heard such a voice of sanity in ages.
Hard to choose between the "thumbs-up" and the "here's a beer for you" icons.
"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."
Did it occur to you that AppKit and Foundation might contain someone else's intellectual property, licenced under terms which do not permit Apple to release the source? Or that key Apple engineers might have recommended opening the source ten years ago and the matter might have disappeared inside Apple's legal department, never to be seen again?
And yes, developers would love Apple for it -- not always developers on Apple platforms, mind.
"Stop using undocumented APIs in application code. Microsoft did it and got hammered for it."
Microsoft got hammered because they used undocumented APIs to create an illegal anti-competive advantage; interoperable SMB implementations are a different ballgame to nonstandard prettiness added to GUIs.
I find Apple's arguments about undocumented APIs to be convincing; if it's not documented then it's not supported and may change or disappear without warning in a future release. If I was a software vendor I would consider being required to document and support all hitherto-private APIs would be to incur a huge cost that I'd prefer to avoid.
No offence Dave, but I don't really see why The Register needs a Mac Secrets column about MacOSX software development at all.
"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.
What you really mean is they have no market. No one cares about them.
A 'boi' can be either male, female or various points inbetween. HTH HAND.
So far as undocumented interfaces go, the important point is to ask : who profits?
If Apple could not potentially profit from their use of undocumented APIs, then it probably isn't an issue. As soon as it either provides a competitive advantage, or functionality that is solely available via a single commercial package, then the interface must be opened up.
We're everyone's friends. We help all of you (users / software houses / distro builders etc etc).
We face the problems that are on some bug or feature list and we deal with the disgruntled people.
We also often provide the cross-product interfaces that you wont make for commercial reasons but are needed in the real world to make people use your products!
In short, we're f*cking great and you all need us.
(yes, i am a developer)
"…because 64-bit operation is the default modus operandi under Snow Leopard…"
What do you mean by that, exactly? As far as I know, Snow Leopard behaves just like Leopard, supporting 32bit and 64bit apps. Also, for now it defaults to booting in 32bit kernel mode.
He kernel defaults to 32 unless you run a server. But the apps default to 64 bit.
If they're from East Anglia - yes we have computers out here - are they Fanbors?
That would give us a new test for Norfolkness:
Q. "Ha' yer fa'r got a eye-mac, bor?"
A. "Yis, an' he want a fule ter yuz it, will yew cum? "
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.
