Recently I have get a reject from Apple because a use of a private API. I don't know exactly what is a private API nor an undocumented method. Could someone explain me what is an undocumented method and a private API? I'm really confused with that...
Follow up:
What is exactly the "official documentation"? Can I use some frameworks and classes made by thirds such as the Amazon one?
A private API or undocumented method is any object or method that is not part of the official documentation. In Objective C, and some other languages, it is relatively easy to find the list of methods (messages) that an object supports as well as the objects underlying the framework. (For example, just go into the debugger and look at the view hierarchy. You will likely see several view objects that don't exist in the documentation.) Sometimes you will even see instructions on how to use these methods and objects on the web.
One example that leaps to mind is -UIWindow _autolayoutTrace, I use it all the time when debugging autolayout, but it isn't documented and the leading underscore is a hint that you shouldn't be using it. That's fine for debugging, but if I shipped code that used that method it would be certain to be rejected.
But Apple specifically scans for these undocumented methods as part of the App Store review process and rejects apps that use them. This is because Apple might change how these undocumented methods work at any time. If your app was dependent on one of these hidden classes or methods your app might break when Apple released a new version of the SDK that changed this behavior.
There's a set of functionalities that Apple uses internally but are not publicly available for developers.
Any usage of such APIs will result in a rejection of the application by Apple.
Related
Does Apple allow the usage of sysctl.h within iOS applications?
PS: App Scanner, a third party tool that checks code for possible private-API usage seems to think it's okay.
Note:
There is one more question like this : How can I know if I'm using private frameworks?
With the usual disclaimer that nobody can tell you what a reviewer will do, I can say for sure that there are apps in the store that use sysctl functions.
(Minor point: Simply including a header isn't a problem since symbols there shouldn't be visible in your app unless they're used...it's the things you use that might get flagged rather than what's included.)
OSX has functionality not available in the iOS SDK, and occasionally I'll find an answer like this one: no route.h on the iPhone SDK, that says "just copy the header file from the Simulator (or OSX) SDK and it'll work fine."
That seems suspect to me on multiple levels, including App Store approval, but then I read something like this from an Apple employee who says "if you're using sys/route.h declarations on iOS for an App Store app, please get in touch with me...", which sounds like tacit approval (or a ruse to catch misbehavior :)
Anyone know where the official line really is, and whether something like this is at all safe to do in production code? I'm particularly interested in lower-level BSD functions and whatnot for portability, as opposed to undocumented Objective-C methods.
I would not regard that comment on the Apple forums as tacit approval. It sounds like they're just trying to decide if some additional BSD APIs should be added for use in iOS apps.
In general, if there isn't an iOS header available for a function, then it's considered a Private API (for example, something under https://developer.apple.com/library/ios/). The official policy on Private APIs is that they're not to be used in apps distributed through the App Store.
Now, you can certainly use them for personal/hobby apps, or apps that you deploy in-house (Enterprise Distribution).
If the APIs you're talking about are APIs that are publically documented for OS X, and you can get them to work for iOS by copying headers, then they're probably part of the Darwin source base. It's very likely that they'll continue to function in future versions of iOS, although that's not guaranteed. Of course, nothing is guaranteed (really), as public APIs get deprecated, too.
Then, there's the issue that not all review checks are automated (I don't work for Apple, but can deduce this from things I've seen get through review). It isn't that unusual for apps to be approved with Private API usage, although if they get popular, Apple frequently pulls those apps from the store within a couple weeks. The review process isn't perfect.
So, my answer is that if you're submitting to the app store, don't expect copying in headers to work.
P.S. If you can tell us specifically which BSD function you're referring to, we might be able to give you a better answer.
P.P.S. The answer you link to about Route.h is from Grant Paul, who writes quite a bit of non-App Store software.
Additional useful information on Private APIs and the App Store
Apple never knows what header files you use - the danger of course is the definition from the copied file is close to, but not exactly, what iOS uses. If this file is important, or a few select files, post a question on Apple's internal forums and you will surely get an answer to such a question. Failing that, burn a DTS incident (you get two a year, I almost never use mine).
I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.
Does using (for example) UIWebView's subviews count as using undocumented APIs? There is no documentation on the fact that the first subview of a UIWebView is a UIScrollView. Does that mean that I am not allowed to add children to this UISCrollView?
I'm not using any private calls, but it isn't documented anywhere. In iOS 3.1 the first subview of a UIWebView is an instance of a class called "UIScroller", which is almost identical to the UIScrollView, but not documented anywhere. What is allowed exactly?
From UIView Class Reference
For complex views declared in UIKit
and other system frameworks, any
subviews of the view are generally
considered private and subject to
change at any time. Therefore, you
should not attempt to retrieve or
modify subviews for these types of
system-supplied views. If you do, your
code may break during a future system
update.
From App Store Review Guidelines:
Apps that do not use system provided
items, such as buttons and icons,
correctly and as described in the
Apple iOS Human Interface Guidelines
may be rejected
Taken together, I read these as saying: You can look at the subviews of standard components, but mess with them at your own peril -- things will change with no notice, and you'll have nobody to blame but yourself when they break. Furthermore, if you do modify a standard component in a way that's out of keeping with what Apple designed and users expect, your app will likely be rejected.
Modifying the private subviews of UIWebView seems like a poor plan.
I don't think it counts as using private APIs (correct me if I'm wrong), but I wouldn't recommend it. As you say: "in iOS 3.1" it works that way, but it's not guaranteed to work the same on other versions. It may change with an update and the application will break.
By the way, very few use iOS 3.1, so I would recommend looking at how it works in 4.3.
EDIT: I have never uploaded an app to app store where I've done this, but I can tell you this much: You do not submit any source code to Apple. They run your executable in a tool that will detect if you call any private API methods.
Looping through subviews is allowed. So is adding subviews. They don't even mention this in the guidelines. I can't make any guarantees, since I'm not involved in Apple's review process, but I would be very surprised if they would reject your app for this reason.
If you feel like it would add value to your app I would go ahead and do it. If you submit your app to the app store and get it approved, please come back and leave a comment.
While I understand that in order for an iPhone application to be accepted on the App Store, one requirement is that only documented libraries are to be used.
If this is the case, how are certain applications such as "Night Camera" and "Camera Plus" using a camera control that seems to be something other than the one contained within UIImagePickerController?
I have heard of certain cases where a developer has been given "special" access to certain headers that allow for features that would otherwise be impossible if constrained to only using documented libraries. However, given how opaque the application selection process is for the App Store, I would prefer to stick to what is recommended rather than take my chances.
Anyone care to shed some more light on this?
Have you seen this dicussion?
http://blog.airsource.co.uk/index.php/2008/11/11/views-of-uiimagepickercontroller/
and this sample code for a custom picker?
http://www.codza.com/custom-uiimagepickercontroller-camera-view
hope it helps.
You might want to check out a classdump of apple's private framework headers. Run this perl script:
http://arstechnica.com/apple/news/2008/11/dumping-the-iphone-2-2-frameworks.ars
and navigate to the PhotoLibrary directory under PrivateFrameworks. Some of the classes in here look pretty promising for direct camera access.
Using the undocumented API could hurt your chances of passing through the app store, but it's all very subjective - If your product is good, apple will probably let it slide through. I'd recommend making friends with a developer evangelist at Apple.
The UIImagePickerController is a UIViewController subclass that manages a view hierarchy. You are free to play around with the view hierarchy, as those apps are, but it is risky considering that Apple does not document it and could change it on any OS update.
I have not heard of anyone being given special access to libraries, but I have read that there is a minor distinction between undocumented classes and methods and private frameworks. Undocumented classes are a gray area, but private frameworks are definitely not allowed.
The simple explanation is that apps in the store are not supposed to use unsupported APIs, but this is not checked consistently. The apps you mentioned are either using unsupported functions/classes/methods or else are playing with the view hierarchy-- which is itself undocumented even though it can be done with standard APIs.
You could do what they do, and take your chances with it. Just be aware of the risks. Your app might (a) be rejected from the store, (b) be accepted but later booted (this has happened for unsupported API use), (c) be accepted and not booted but break the next time Apple has a new iPhone software update (since unsupported APIs or view hierarchies can change without warning). Or you could get lucky and have none of this happen.