What exactly is a Private API, and why will Apple reject an iOS App if one is used?

Question

I've read several articles about this, and I just want to see if I understand this correctly:

Apple will reject your app if you use a Private API...

1. What is the main difference between a "Private API" and a "Non-private API?"

2. Are the "Non-private" APIs only the APIs provided and verified by Apple?

3. Isn't an API just a way of interacting with a Framework, and a Framework is just a set of encapsulated classes/headers that people can use for trivial purposes?

4. Wouldn't this mean that I cannot reuse anyone's code (other than Apple's) at all in my app?

5. If this is true, whenever a programmer makes his or her own custom classes and methods, isn't he technically designing a mini Framework just for his specific purpose? So wouldn't this mean that he is using his own private API?

6. What would even be the difference between using someone else's classes/methods alongside my classes/methods, how could they even tell the difference, and why would this be a problem?

My understanding of this sounds absurd, and don't believe I am understanding what a "Private API" is correctly. I did read that it was to protect against any changes in the API that could render your App dysfunctional. Does this mean APIs are linked during run time (as opposed to compile time) and can be updated automatically without you knowing or something? (See, I was originally thinking of APIs/frameworks as being set in stone whenever you compile, maybe this is where I am wrong)

Can someone please help me out? I'm really confused about this policy.

Timework

by definition, your own classes and whatnot in your own app are your own, and private. They mean private api as in using functionality provided by iOS for internal-use only. e.g. as a hacked up example, you're allowed to use a SystemClock api, which under the hood uses a private HardwareClock API. Your app using SystemClock would be ok. But bypassing that and going straight to HardwareClock will get your app booted. – Ballista

Apple's private APIs rule is about not using private Apple APIs. Apple has documented many of their APIs, but some are undocumented. These undocumented APIs are the private APIs that Apple's guidelines refer to. – Terri

possible duplicate of Apple and private APIs – Thetos

To put it simply: private API != third-party API – Thetos

I see, thank you! I think I read too many articles with wrong info in them and got confused lol – Timework

Answer 1

Q. What is the main difference between a "Private API" and a "Non-private API?"

• Private is one that isn't publicly defined (there isn't much to it)

Q. Are the "Non-private" APIs only the APIs provided and verified by Apple?

• Private and Public APIs are both 'provided' by Apple but only public APIs are provided for you to use.
• The private APIs are for use by Apple only

Q. Isn't an API just a way of interacting with a Framework, and a Framework is just a set of encapsulated classes/headers that people can use for trivial purposes?

• Yes

Q. Wouldn't this mean that I cannot reuse anyone's code (other than Apple's) at all in my app?

• No

Q. If this is true, whenever a programmer makes his or her own custom classes and methods, isn't he technically designing a mini Framework just for his specific purpose? So wouldn't this mean that he is using his own private API?

• No (a framework is different to an app)

Q. What would even be the difference between using someone else's classes/methods alongside my classes/methods, how could they even tell the difference, and why would this be a problem?

• It usually wouldn't

---

The point you need to get is that when referring to private APIs you should only be thinking about private Apple supplied APIs.
Other APIs from 3rd parties are different (and Apple doesn't care so long as that 3rd party code doesn't use Apple private APIs).

Manhandle

I gotcha. I feel like there's a lot of misleading infornation about private APIs out there that I read, and it was hard to understand since some people were saying it was one thing and some people were saying it is another. And I think Apples information about Private APIs are that they are "Undocumented APIs" and it doesn't exactly explain what they mean by "undocumented." Thanks for clearing it up! – Timework

@Manhandle can you give an example of what a private api is or what is looks like? – Longueur

@SamBudda, let's go with UIDevice uniqueIdentifier which used to be public, but which is now private. You used to be able to use it to identify the device your app was running on, but it's abusable to try to identify the user, so now it's private and there are a number of more specific alternatives for different purposes. So, a private API doesn't 'look' like anything specifically. – Manhandle

Are there ways of finding out apple's private apis? I mean if it is private then that means there is no documentation for it (not publicly available in apple docs) so how does one find a private api? trail an error? hacks? – Longueur

@SamBudda, why do you want to find them? class-dump is your friend. – Manhandle

@Manhandle One possibility is for developing jailbreak tweaks or apps, then provate APIs are fair game :) – Declinometer

I wonder why Apple still allows any code that accesses their private APIs to compile at all... – Auger