06:11 pm, 24 Sep 08
system programming interface
Today someone used the term "SPI" ("system programming interface") and I didn't know it, so here's what I've gathered and maybe some commenter will correct my misunderstanding.
It's apparently an Apple term for "private API". This slashdot comment explains pros and cons in more detail, but the general gist is: Apple provides API, which is documented for app use and intended to remain stable, and then there is SPI, which is whichever extra functions were needed to make their apps work. Since Apple can release the OS and apps at the same time they can change the SPI on a whim.
From the inside-Apple developer perspective, this makes total sense: when you need some extra hooks and the developers are just down the hall, why not? And it's good to let the public know that these extra calls aren't guaranteed to remain stable. But from a 3rd-party application developer's perspective, this is also totally insane: there are all of these calls that are only available to blessed company software!
Given the two sides, I haven't yet decided how I actually feel about it. Certainly Microsoft gets widely blamed (and even punished) for doing this sort of thing, but Apple tends to get a free pass wrt being hostile to developers for reasons I don't yet understand. And ultimately it seems a natural consequence of the platform owner also being a competitor in the platform's software market -- they'll always have an advantage, and that's just the price you pay to play on their platform.
It's apparently an Apple term for "private API". This slashdot comment explains pros and cons in more detail, but the general gist is: Apple provides API, which is documented for app use and intended to remain stable, and then there is SPI, which is whichever extra functions were needed to make their apps work. Since Apple can release the OS and apps at the same time they can change the SPI on a whim.
From the inside-Apple developer perspective, this makes total sense: when you need some extra hooks and the developers are just down the hall, why not? And it's good to let the public know that these extra calls aren't guaranteed to remain stable. But from a 3rd-party application developer's perspective, this is also totally insane: there are all of these calls that are only available to blessed company software!
Given the two sides, I haven't yet decided how I actually feel about it. Certainly Microsoft gets widely blamed (and even punished) for doing this sort of thing, but Apple tends to get a free pass wrt being hostile to developers for reasons I don't yet understand. And ultimately it seems a natural consequence of the platform owner also being a competitor in the platform's software market -- they'll always have an advantage, and that's just the price you pay to play on their platform.
It's hard for people to take a firm stand against something everyone does. In this case, it's like being against speeding because it wastes gas. Everyone that has to buy gas in a fungible market feels some affinity with that position, but most people speed essentially every time they drive more than a couple miles, and those who don't are usually more concerned about the risk.
Publishing APIs ought to be taken really seriously. It's a commitment that those APIs will work and do what they say they do, and continue to be supported. Binary compatibility is very important in the Mac OS, and it can be really, really unpleasant to have to support a bad API that is preventing the implementation underneath it from being improved.
For this reason, it is strongly encouraged within the OS X group to not publish new functionality as a public API the first time it's released. There often isn't enough time in one release cycle to implement the functionality, get it working in internal apps, and also produce a polished, usable, stable API that can be supported for years to come. Very often the API gets cleaned up and made public in the next release. (The entire iPhone API is an example of this.)
Also, a lot of private APIs are there just to get pieces of the system to work well together, but they expose too many implementation details. (They might also be very low-level and irregular and hard to document.) They're the kind of things that can work when everyone using them is on the same mailing list and on the same release cycle and can coordinate changes to their code, but that you would never want a shrink-wrap product to use. A lot of window-server / CoreGraphics infrastructure is like this; things that are used under the hood by the Cocoa and Carbon frameworks but that apps shouldn't mess with.
(I'm sure Linux doesn't care about stuff like this; but Linux seems to expect that you're either building stuff from source yourself and dealing with dependencies, or are sticking with a prepackaged distro.)
Personally I think it makes total sense from a developer perspective, on either side of the line. There's a long tradition of this kind of thing even in free software, with things like #define WNCK_I_KNOW_THIS_IS_UNSTABLE. Now, that Apple gets a free pass on it, yeah, bullshit, but the codependent relationship between the nerd community and Apple is well established.
There is also a distinction among non-frozen APIs where some are "private" and some are not private. There was an attempt to prefix private interfaces with nsPI (rather than nsI), but I don't think that gathered much momentum.
That said, in practice, you try to avoid changing a non-frozen interface if a popular extension uses it. Either that or you work with the extension developer to make it easier to transition. I imagine Apple does the same and tries to avoid changing an SPI if popular third party software depends on it. I think this is inevitable with all software.
To steal from Raymond Chen (who wrote about this in the context of Microsoft): the user doesn't care whose fault it is, all they care about is that when they upgraded your program, things broke. Thus, if they upgrade Firefox and one of their extensions breaks, 'clearly' it must be the fault of those darned Firefox coders and in fact, maybe it would be safest to never upgrade Firefox again.
I suspect that Mozilla feels this is an undesirable mindset for their users to have, so they're willing to go to extra work to avoid it, no matter whose fault it actually is. And on a purely pragmatic basis, people usually won't upgrade a program if the upgrade breaks things, so if you want rapid and large uptake of an upgrade (perhaps it is a security update) it pays to bend over backwards to avoid breakage (again, no matter whose fault it would be).
If the end result is that Photoshop (or Office, or some other major app.) won't run on the new version of the OS because it calls some undocumented routine that went away or changed behavior, then that means large numbers of customers won't upgrade the OS until that app is upgraded to be compatible, which might take a year or more. [Note the similar situation where sales of Intel Macs jumped as soon as the Intel-native Photoshop became available.] That would be unacceptable, and the alternative of hacking special-case code into the OS to work around such compatibility problems is pretty bad, too.
Similar situations apply where many apps use a 3rd party library that misuses such SPI. Individually those apps might not be as critical, but if there are dozens of them, it can add up to a serious problem.
Presumably the price that a platform developer pays for favoring its own apps on its platform is that it's less attractive to third-party developers. Perhaps this is one reason why there seems to be less of a developer community on Mac than on either Windows or Linux/Unix1, and what apps there are tend to be shareware/payola rather than free of charge or open source.
[1] I write this at the risk of drawing fire from regular Mac users. I might be well out of date with this assertion. I guess these days a lot more geeks are using MacOS so maybe there's been an influx of no-charge and open source software that I'm not aware of.
Microsoft
Working on Visual Studio, we actually have rules (and automated tools to enforce them) that we're not allowed to use any undocumented Windows API's in our code.So in general, I think Microsoft tries not to do this. But there may be exceptions that I'm unaware of. Or maybe we got in trouble for it in the past or something.
"The more widespread the use of private iPhone APIs becomes, the more likely it is that the iPhone will become the sort of platform where users resist installing OS updates, on the grounds that previous OS updates “broke” third-party applications they had installed."