Guideline 2.5.1

Guideline 2.5.1 - Software Requirements: Using Private or Undocumented APIs

High SeverityHard FixTypical Fix: 1-3 days0 Reports

Also known as:App uses or references non-public APIsApp uses deprecated API that is no longer permittedThird-party SDK in your app references private APIsApp uses undocumented system interfacesBinary contains references to private framework methods

Our Take

Apple is rejecting your app because it uses private or non-public APIs -- system interfaces that Apple has not documented or made available through the official SDK. Apple scans every binary for private API usage, both at submission time (automated) and during review (manual). This is one of the most technically frustrating rejections because the private API usage may come from a third-party SDK you included, not from your own code. Private APIs are interfaces that exist in the system frameworks but are not declared in the public headers. Developers sometimes discover them through runtime introspection, class dumps, or reverse engineering. Apple prohibits their use because: (1) they can change or disappear in any OS update, causing apps to crash, (2) they may access sensitive data or capabilities that circumvent platform security, and (3) Apple hasn't validated their behavior for third-party use. The rejection also covers deprecated frameworks. When Apple deprecates a framework and sets a deadline for removal, apps using it after that deadline will be rejected. This commonly hits apps using UIWebView (deprecated in favor of WKWebView) or older APIs that have been superseded.

Resolution Guide

Identify the source

Search your entire project (including Pods/SPM dependencies) for the specific API names Apple listed. Use grep -r 'apiName' . across your project directory including all dependency source code.

Check third-party SDKs

The most common source of private API usage is third-party SDKs, especially ad networks, analytics SDKs, and jailbreak detection libraries. Check if updated versions of these SDKs have removed the private API calls.

Replace with public alternatives

For each private API, find the public equivalent. Apple's documentation and developer forums usually have migration guides. If no public alternative exists, file a Feedback Assistant request and find a different approach.

Handle false positives

If you have a method with the same selector name as a private API (e.g., your own _deviceName property), rename it to avoid the automated scanner. Explain this in your review notes.

Scan your binary before submission

Use nm -u YourApp.app/YourApp | grep '_UI' or similar tools to check for private symbol references before submitting.

Replace UIWebView

If the rejection mentions UIWebView, migrate to WKWebView. This also applies to third-party SDKs that still use UIWebView internally.

Prevention

Audit third-party SDKs for private API usage before integrating them

Keep all SDKs updated to their latest versions

Use Apple's public API migration guides when APIs are deprecated

Run grep for common private API prefixes (_UI, _NS, _CK) in your binary before submission

Example Rejection Email

From:Apple App Review Team

Subject:Guideline 2.5.1 - Software Requirements: Using Private or

Guideline 2.5.1 - Performance - Software Requirements Your app uses or references the following non-public APIs: - _UIStatusBarForegroundView - UIDevice._deviceName - LSApplicationWorkspace.allInstalledApplications The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change. Next Steps: Please revise your app to remove any non-public API usage. If you believe you need functionality that is not available through public APIs, submit a feature request through Feedback Assistant.

Consider Appealing

If the private API reference is a false positive (e.g., your own method happens to have the same name as a private API), explain this in detail with code snippets. If the reference comes from a third-party SDK, explain that you'll update the SDK and provide a timeline.

Generate Appeal

Before & After

Before — Rejected

App uses UIDevice._deviceName to get a human-readable device name, and includes an analytics SDK v2.1 that references _UIStatusBarForegroundView

After — Approved

Device name retrieved using public UIDevice.current.name API. Analytics SDK updated to v3.0 which removed all private API references. Binary verified clean with nm tool.

What changed: Always trace private API usage to its source -- often it's a third-party SDK, not your own code. Update SDKs first, then check your own code.

Community Solutions · 0

More Guideline 2 (Performance) rejections

View all Guideline 2 rejections