"Restricted API" covers two different things that both cause problems at submission, and knowing which one you mean changes how you check. There are private, non-public APIs, which are outright banned and get you a 2.5.1 rejection, and there are required reason APIs, which are allowed but must be declared in your privacy manifest. Both often come from a dependency you did not write, so checking your own code is not enough. Here is how to find each kind in your app before Apple does.
Short answer
To check whether your app uses restricted APIs, you need to inspect the compiled binary and your dependencies, because the two kinds of restriction differ. Private, non-public APIs are prohibited and trigger a Guideline 2.5.1 rejection, while required reason APIs, like UserDefaults and file timestamps, are allowed but must be declared in your privacy manifest. Apple's automated checks flag both at upload, with emails about missing privacy manifest entries and rejections for private API references. The reliable way to find them yourself is to scan the binary for the symbols and audit each SDK, since a dependency commonly introduces a restricted API without your knowledge.
What you should know
- Two kinds of restriction: private APIs are banned; required reason APIs need declaring.
- Private APIs fail 2.5.1: referencing non-public symbols is a rejection.
- Required reason APIs need a manifest: declare an approved reason for each.
- Dependencies are the usual source: an SDK can pull in either kind.
- Scan the binary to find them: source review alone misses what SDKs add.
What counts as a "restricted" API?
Two categories, with different rules. The table separates them.
| Kind | Examples | Rule |
|---|---|---|
| Private, non-public APIs | Undocumented selectors and symbols | Banned; causes a 2.5.1 rejection |
| Required reason APIs | UserDefaults, file timestamp, boot time, disk space, keyboard | Allowed, but must be declared in the privacy manifest |
| Entitlement-gated APIs | Capabilities needing a specific entitlement | Allowed only with the entitlement granted |
Private APIs are the strict no: Apple's automated analysis scans your binary for symbols matching non-public selectors and rejects the app under 2.5.1. Required reason APIs are different, since they are legitimate to use, but Apple requires you to declare an approved reason for each in your PrivacyInfo.xcprivacy file, and missing declarations draw warnings or rejection. So "restricted" might mean either, and the fix depends on which.
How do you check your app for them?
Inspect the binary and the dependencies, and heed Apple's automated signals. Start with the upload feedback: when you upload a build, Apple's automated checks email you about required reason APIs used without a manifest entry and reject builds that reference private APIs, so those messages name the problem area. To find issues before that, scan the compiled binary for the symbols rather than trusting a source review, because a dependency can introduce a restricted API your own code never calls. Audit each third-party SDK, checking whether it declares a privacy manifest and whether it is known to use private APIs, and update or replace any that do. The goal is to know what symbols and APIs are actually present in the build you submit.
What do you do when you find one?
It depends on the kind. For a private API reference, you must remove it, which usually means finding the SDK that introduced the symbol and updating it to a version that no longer uses the private call, or replacing the dependency entirely, since you cannot ship the private reference. For a required reason API, you do not remove it; instead you add the approved reason to your privacy manifest, and if a dependency uses it, gather that library's required reasons into your app's manifest. For an entitlement-gated API, confirm you have the entitlement and that your usage matches it. In every case, the move is to identify the exact symbol and the code that brought it in, then act at the source.
What to watch out for
The first trap is assuming your own code is clean and stopping there, when restricted APIs most often arrive through a third-party SDK. The second is treating a required reason API like a private API and trying to remove it, when it just needs a manifest declaration. The third is ignoring Apple's automated upload emails, which point straight at the problem. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the SDKs, symbols, and API usage in your build, so you can see which restricted APIs are present and which dependency introduced them before review flags it. That turns a guessing game into a targeted fix.
What to take away
- "Restricted API" usually means either a banned private API, which causes a 2.5.1 rejection, or a required reason API, which is allowed but must be declared in your privacy manifest.
- Both commonly come from a third-party SDK, so checking only your own code misses them.
- Use Apple's automated upload feedback, audit your SDKs, and scan the binary for the actual symbols present.
- For a private API, remove or replace the SDK; for a required reason API, declare it; and use a pre-submission scan such as PTKD.com to find which are in your build.
