Speaking of Storm8, Unity-engine code, private API, and Gruber, A recent Twitter exchange between him shows just how seriously all of this is now being taken by the App Store:
Hockenberry: Hearing lots of reports about apps getting rejected due to private API usage. Maybe now you'll believe me when I say it's a bad idea…
Gruber: Yup: Apple recently started running apps through a static analysis tool to look for private API calls.
Google set off some of the private API discussion when they implemented them as part of the Google Mobile app (though it's our understanding those API were later made public). Generally, private or unpublished API are kept that way because Apple (or whichever platform maker is supplying the APIs) hasn't finished working on them, are planning changes, or is otherwise reserving their use -- if 3rd parties implement them anyway, any future OS update can break them and cause problems for end users. Public API, on the other hand, are supported and intended to let developers do their thing without worrying about platform-level changes wrecking their apps.
Reader comments
Apple Using Static Analysis Tool to Find Private APIs, Reject Apps
RON JEREMY SAYS he's first. And still loves you.
Good that Apple is cracking down!
wow. your a stalker. twitter sucks. end of story.
Bought bloody time!
When you use private APIs for a platform, you risk your apps breaking when the platform upgrades.
When you use private APIs for a platform with an absolute gatekeeper, you risk...well, that level of risk is so stupid it is hard to quantify.
I wish I understood what this article was about. I don't know the difference between private and public APIs...heck, I'm not sure I know what an API is.
As an iPhone owner, what does this mean to me? Should I be concerned?
Who is Hockenberry? I know Gruber is the Twitter guy...oh geez. This article was a little too "inside" for me...I read all the stories on TiPB and it ticks me off when I come across stuff like this that makes little sense.
These must be the only two people on Twitter who use punctuation, uppercase, and correct spelling.
I thought the whole object of Twitter was to abbreviate every word, making it unreadable, then to end up with at least 80 characters leftover. :roll:
@Spicerak2:
Private APIs are designed for use by Apple.
Public APIs are designed for use by any developer.
This lets Apple develop applications that no developer could do. It gives them an edge.
Microsoft got in a lot of trouble doing the same thing, and the EU and the Justice department forced them to document and release all these private APIs used in Applications like Word, and MSIE.
This does not pertain to operating system APIs that can execute privileged function calls etc.
Just those APIs that give Word an advantage over OpenOffice, or Internet Explorer an advantage over Firefox.
See http://www.groklaw.net/articlebasic.php?story=2007020819534335
Historically, these things cause as much problems as they solve, as they are conduits for viruses an malware.
Typically you would not document these, or you would hide the entrypoint for these APIs in a different module than the normal APIs and you would not provide a library describing where they are and what they do.
Scanning for use of these Private Apple APIs is sort of a pointless exercise because anyone capable enough to dig around in Apple's API structures and determine the function of these APIs and how to call them is also capable of obfuscating the call, such that no direct linkage exists in the code until the millisecond prior to the call actually happening.
Its a design flaw of the iPhone sandbox that any non operating system program can actually GET TO these APIs at all. This is not the first such sandbox leak discovered, the applications that free memory by shutting down other apps are another example.
@ icebike, the hero
Thanks...that does clear up the confusion. :)
@SpiceRak2
One further emphasis -- there are some legitimate reasons to keep APIs private. Typically, if you do not want to expose some ugly internals that people do not otherwise have to see, or want to reserve the right to change something on a whim, you would the APIs around it private. Once you publish and document methods, and people start relying on it, you have an obligation to keep it. As the old saying goes "programming is like sex -- make one mistake and you have to support it for the rest of your life." :)
Microsoft got in trouble not for having private APIs in Windows per se, but for giving access to solid APIs to the Office team, but not competitors. As icebike points out, this gave the MS Office team some built-in advantages no competing office/browser could hope to overcome, and the US DoJ and EU eventually took notice. The private APIs themselves were not the problem, just that inequitable distribution.
I doubt any government body would frown on Apple having private APIs, unless somebody could make a case they were doing something similar to force competing products off the iPhone/Mac platforms.
@Dev: Wonderful. Thank you.
@Dev and/or @icebike
Sorry to be such a neophyte, but could either of you expound by example, the ways this creates an "edge" or "advantage" over the competition? I am having trouble understanding that essential part. Thanks.
If I am understanding the advantage created by Microsoft's non-distributed APIs, MS Office applications were able to perform in the OS in ways that other applications could not. Right? Or am I mixed up? Lol.
Here's another example of a static analysis rejection that sounds like a false positive: http://www.juicybitssoftware.com/2009/11/07/static-analysis-rejection/
@SpiceRak2
You have it about right -- that is the competitive temptation any platform provider that also sells software for that platform faces.
Here is drastically oversimplified made-up example. Suppose in MS Windows there is a published way to draw a window, and that way is to give it the 4 corners like this:
drawRectangle(topLeft, topRight, bottomLeft, bottomRight);
That published way is the public API to draw a window, and the folks at WordPerfect, Netscape, and everybody else will use that method, because, well, that is the way to do it when working in Windows.
Now, suppose the Windows team at Microsoft has some other method they use privately:
drawParalellogram(topLeft, topRight, bottomLeft, bottomRight);
Nothing wrong with having a private method -- a window drawing application does not care or need to know Windows calls it a parallelogram internally anyways. Code libraries hide details like that on a need-to-know basis all the time.
But say this method draws windows 50% faster. Then say the Windows team lets the Office team know about and use this method, but does not publish it so that the Wordperfect folks can use it too.
Now, MS Office will draw all its windows 50% faster than Wordperfect, and there is no way for Wordperfect to counter or even replicate MS Office superior snappiness. Even if Wordperfect figures out this private API, since it is not published, MS could reserve the right to break it in the next version, leaving Wordpefect the devil's choice of being slower, or working harder to be as fast and risking breaking completely in the future. The playing field for Office software is no longer level.
This is a completely contrived example, and, despite what I said in the post above, I do not think anybody ever showed MS did this, only that the at the time pundits bandied about splitting MS into separate Windows and Office companies to prevent this sort of thing from taking place.
@Dev: Even better. This makes a lot more sense. I re-read this entire post with much mire confidence and understanding. Thank you!
I'm seeing some of the futility, as icebike said earlier, of finding private APIs...as this creates a greater risk of breaking apps, should those APIs be modified in the future. Now, Apple is spending energy trying to detect their unauthorized usage rather than preventing developers from finding them in the first place.