Guideline 2.5.1 Rejection: How to Fix Software Requirement Issues and Resubmit
Guideline 2.5.1 covers what your binary is allowed to be built from: only public APIs, used for their documented purpose, on currently supported technologies. Rejections here are code-level by definition — a metadata edit never fixes them. The usual suspects are a third-party SDK calling a private selector, direct use of non-public frameworks, or deprecated tech like UIWebView still linked somewhere in your dependency tree.
What Apple's rejection email says
"Guideline 2.5.1 — Performance — Software Requirements. Your app uses or references the following non-public or deprecated APIs: [selector or symbol names]. The use of non-public or deprecated APIs is not permitted on the App Store, as they can lead to a poor user experience should these APIs change. Next Steps: Please revise your app to remove any non-public or deprecated APIs."
Often the same class of problem surfaces earlier, at upload, as an ITMS email — e.g. "ITMS-90338: Non-public API usage" or "ITMS-90809: Deprecated API Usage — Apple will stop accepting submissions of apps that use UIWebView APIs."
Typical App Review wording for Guideline 2.5.1. Exact text varies per app.
Why apps get rejected under 2.5.1
Concrete root causes seen in 2.5.1 rejections:
- A third-party SDK using private APIs. The most common source. Analytics, ad or "device fingerprinting" SDKs — especially older or closed-source binaries — sometimes call private selectors. The flagged symbol is in your app because the SDK is.
- Direct private API use in your code. Calling undocumented selectors via
performSelector:, poking at private classes with the Objective-C runtime, key-value coding into private ivars, or linking frameworks Apple hasn't published headers for. - Deprecated technology.
UIWebViewis the canonical example — new submissions containing it are rejected; migrate toWKWebView. Similar treatment applies to other long-deprecated APIs Apple has formally sunset. - Public API used for a non-documented purpose. 2.5.1 also covers misuse — e.g. abusing background modes or entitlements to do something the API wasn't intended for.
- Symbol-name false positives. Apple's scan is partly static. A method you wrote whose name happens to collide with a private selector can trip the detector even though your code is innocent.
Step-by-step fix
- Get the exact symbol list. The rejection (or the ITMS upload email) names the selectors, classes or frameworks. Copy them verbatim — the fix is a search problem first.
- Search your own source. Project-wide search in Xcode for each symbol. If it's your code, replace it with the public equivalent or rename the accidentally colliding method.
- Search compiled dependencies. If source search finds nothing, the symbol is in a binary dependency. From a terminal, run
strings/nmagainst each framework in your app bundle (e.g.grep -r "symbolName" Pods/, thennm -uon the .a/.framework binaries) to find which SDK contains it. - Update or replace the offending SDK. Check the vendor's changelog — established SDKs usually ship a cleaned release quickly after Apple starts flagging something. If the SDK is abandoned, remove it or swap vendors.
- Migrate deprecated tech. For UIWebView: replace usages with
WKWebView, then confirm the symbol is fully gone withgrep -r "UIWebView" .across the project and Pods — a single reference in an old dependency still triggers ITMS-90809. - Rebuild and validate before submitting. Archive in Xcode, then use Organizer's Validate App (or upload via Transporter) — many 2.5.1-class issues are caught at validation, giving you a faster loop than a full review round.
How to resubmit
2.5.1 always requires a new binary: bump the build number, archive, upload, wait for processing, select the new build on the version page in App Store Connect and submit for review. If you're confident the flag is a false positive (a name collision with a private selector), reply in the App Review thread explaining exactly which method it is and what it does — reviewers can and do clear these. A formal appeal is rarely the right tool; with roughly 85% of appeals denied, renaming a method and resubmitting is almost always faster.
How AscAuto handles 2.5.1 rejections
Code-level guidelines like 2.5.1 are where AscAuto's diagnosis-plus-PR flow applies. It extracts the exact flagged symbols from Apple's message, explains the likely source (your code vs. a named dependency), and — if you've connected a GitHub token — opens a pull request with the proposed change: an SDK version bump, a UIWebView→WKWebView migration, or a rename for a collision. You review and merge; AscAuto never pushes to your branches directly. Once your new build is up, it handles the resubmission.
FAQ
Apple flagged a selector I never call. Why?
The scan is static and covers the entire binary, including every third-party SDK you link. Run nm/strings against your frameworks to find which dependency contains the symbol, then update or remove that SDK. Name collisions with private selectors in your own code are also possible.
Can I fix a 2.5.1 rejection without a new build?
No. The problem is inside the compiled binary, so you must remove the API or dependency, rebuild, upload a new build and resubmit. Metadata edits have no effect on 2.5.1.
Is UIWebView completely banned?
For new submissions, yes — apps containing UIWebView references are rejected (ITMS-90809). Migrate to WKWebView and verify no dependency still references the old class before archiving.
What if the private API use is in an SDK I cannot remove?
Contact the vendor — established SDKs ship compliant releases fast once Apple flags them. If the vendor is unresponsive, you have to replace the SDK; Apple does not grant exceptions for third-party code.