Apple appears to be cracking down on apps these days which are not sticking to the SDK agreement when it comes to using undocumented (read “private”) APIs. I’m attempting to make a list here, so if you have received the usual slap on the wrist for actually using one of the undocumented “features” to make it easier on yourself then please let me know so that I can add it here.
The problem with these undocumented API calls is that up until now Apple did not seem to uniformly care if they where to be found in submitted apps. But lately the reviewers seem to have gotten a static analyzer into their hands. With the help of which they can dump all the method names in your app so they will see if you are naughty or nice.
The official statement is that Apple is working on making more and more undocumented API public. They claim that those APIs are not properly tested and will probably change between OS versions thus breaking apps that rely on them. We’ll see if some of these following methods will eventually really become public.
No list of such forbidden APIs would be complete with the grandfather of the all: cover flow. Apple is very protective of stuff that makes apps look like they came from Cupertino. So protective in fact that in the beginning they even slapped guys who created their own coverflow API if it looked too much like the original.
Plausible Labs created their own implementation and because it took lots of work to get right they charge quite a bit for it. $300 to only get a binary library. $2700 to get the source code. Quite a lucrative business concept to be able to sell implementations of classes that should have been made public by Apple in the first place.
What seemed like a useful method to force the iPhone screen orientation came back to bite some people into their respective behinds. Unfortunately there are only rather clumsy workarounds to achieve this behavior, like overriding the shouldAutorotateToInterfaceOrientation or to manually rotate views getting you into lots of trouble with properly resizing views.
With this method people try to get around creating a ViewController just for entering a username and password. Unfortunately Apple thinks that this view should only be used what it’s name suggests, namely displaying alerts. So they made the handy and fully functioning method to add a text field invisible and punish everybody who tries to use it.
Apple seemingly forgot to put the users phone number into a place that cannot be accessed by regular means. So it is still to be found under the key SBFormattedPhoneNumber in the standard user defaults. The problem is that the current version of the Unity 3D engine appears to be allowing access to this value via the built-in Mono scripting engine, causing Apple to reject games using the engine. Update: The problem has already been fixed in Version 1.5.1 of Unity. Apple was tipped off to this number being abused by another case (i.e. lawsuit), but now it appears that they are also scanning your code for instances of the @”SBFormattedPhoneNumber” string.
I had a look, but that seems to be the only “naughty” value in there:
NSDictionary *defaults = [[NSUserDefaults standardUserDefaults] dictionaryRepresentation]; NSLog(@"%@", defaults);
Even though you only use publicly available and documented methods to retrieve this key it’s still now being deemed “private” by Apple.
Another useful and functioning but private view is UIProgressHUD. It’s an undocumented view that gives you an activity indicator plus one or more labels of text. Just what you need to block the main view of your app while you are doing something. Well, you’ll have to roll your own because this one is contraband. Fortunately this is easy to work around as multiple people did already create their own activity indicator label combo.
What did I miss?
attentionClassDumpUser:yesItsUsAgain:althoughSwizzlingAndOverridingPrivateMethodsIsFun: itWasntMuchFunWhenYourAppStoppedWorking: pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:
So please let me know if you found yet another forbidden fruit that would actually be really useful if it where official. And if you do get rejected for the stupid reason of possibly breaking your own apps by using methods that are not being regression-tested then also let me know how you learnt your lession and maybe what you did to work around it.
Most of the time it is way more rewarding to pixelate together your own views to achieve some effects that Apple’s apps seem to have an advantage in having access to.