54

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. Thank you!

slavoo
  • 5,798
  • 64
  • 37
  • 39
giant91
  • 1,153
  • 2
  • 9
  • 18
  • 1
    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. – Marc B Jul 10 '13 at 20:28
  • 1
    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. – cjc343 Jul 10 '13 at 20:28
  • 1
    possible duplicate of [Apple and private APIs](http://stackoverflow.com/questions/1773615/apple-and-private-apis) – Barmar Jul 10 '13 at 20:29
  • 3
    To put it simply: private API != third-party API – Barmar Jul 10 '13 at 20:29
  • I see, thank you! I think I read too many articles with wrong info in them and got confused lol – giant91 Jul 10 '13 at 20:37

1 Answers1

53

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).

staticVoidMan
  • 19,275
  • 6
  • 69
  • 98
Wain
  • 118,658
  • 15
  • 128
  • 151
  • 1
    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! – giant91 Jul 10 '13 at 20:38
  • @Wain can you give an example of what a private api is or what is looks like? – Sam B Jul 10 '13 at 21:16
  • @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. – Wain Jul 10 '13 at 21:26
  • 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? – Sam B Jul 10 '13 at 21:42
  • @SamBudda, why do you want to find them? `class-dump` is your friend. – Wain Jul 10 '13 at 21:44
  • @Wain One possibility is for developing jailbreak tweaks or apps, then provate APIs are fair game :) – Jumhyn Jul 10 '13 at 23:59
  • I wonder why Apple still allows any code that accesses their private APIs to compile at all... – rommex Aug 06 '20 at 05:46