In Apple nomenclature, a private API is an API that your app is technically allowed to call, but that is subject to change at any moment and has 0 documentation and no backwards compatibility guarantees. If Apps were allowed to rely on those, they could just stop working across minor version upgrades or on new devices.
Those APIs are only there because they're needed by some higher-level system library that your app is actually allowed to use.
Sure, you could have all libraries be simple shims, all calls be interprocess, and all security be guaranteed by process boundaries, but that would kill performance.
If you only accept signed code and have W^X protections that apps aren't allowed to disable, this way is simpler, faster and just as secure.
No, all security-sensitive API surface requires being on the other side of a process boundary (and checks on who is allowed to talk to it). “Signed code” is not a thing given that you can just ship an app that can do anything and have its behavior change at runtime (that’s what an interpreter is!)
While this is true, many, many apps use private APIs. Even apps that don’t need them. One common use case is prevent an app from being debugged or run on certain devices - you can achieve that through private APIs.
Even innocuous apps like a calculator can, and do, use them for that purpose.
Almost every major third party app is using some private API or the other. There is even an internal list that Apple keeps of apps that are allowed to do. It’s quite trivial to bypass the App Store checks (which are quite bad and sometimes even flag legitimate use of system APIs).
It was using private APIs.
This is never acceptable as it undermines the entire security architecture.