Guideline 2.5.1: private APIs you did not call

Finding it

The message names something like _setApplicationBadgeString or another selector. Search for that literal string:

# the symbol, across every compiled dependency
grep -rl "SYMBOL_FROM_THE_REJECTION" ios/Pods node_modules 2>/dev/null | head

# and in anything already built
nm -a ios/build/**/*.framework/* 2>/dev/null | grep -i "SYMBOL" | head

# your own code, in case the collision is yours
grep -rn "SYMBOL" ios src app --include=*.m --include=*.swift --include=*.h 2>/dev/null

Then decide which of the three cases you are in:

A dependency uses it. Update it. If the current version still does, the library is unmaintained on this point and the honest answer is replacement, not a patch you carry forever.

Your own symbol collides. Rename it. Annoying, and a five-minute fix.

You are calling it deliberately. Stop. There is a supported way to do the thing, or there is not and the feature does not ship.

Why RN projects hit it more

Depth. A moderate Expo app can pull in hundreds of transitive packages, some with native code, some barely maintained. You did not choose most of them.

Age. Native modules written years ago used approaches that were tolerated then. The list of what counts as private is not static.

Bridging. Some libraries reach into UIKit internals to fix a layout or an animation quirk, which is exactly the kind of code that ends up in this category.

And the RN-specific twist: the rejection arrives with no stack trace and no reproduction, so the instinct is to look for a feature. There is no feature. There is a symbol. Why RN and Expo apps fail differently.

The Android equivalent

Android restricts non-SDK interfaces too, and enforces it at runtime on the device rather than at review. So the failure is not a rejection, it is a crash or a quietly disabled feature on newer OS versions, discovered by users rather than by a reviewer.

Different mechanism, same root cause: a dependency reaching for something it was not given. Google Play rejections.

Preventing it rather than discovering it

Audit native dependencies on a schedule, not before a release. The list of packages with native code is short in most projects, and knowing which they are is most of the work.

# packages that actually contain native iOS code
for d in node_modules/*/ node_modules/@*/*/; do
  ls "$d"ios/*.podspec "$d"*.podspec >/dev/null 2>&1 && basename "$d"
done | head -40

# and which are stale
npm outdated 2>/dev/null | head -30

Prefer maintained libraries for anything touching native UI. This class of problem is almost entirely a maintenance question.

Keep the native dependency count deliberate. Every native package is a way for someone else's decision to become your rejection, which is the same reason a capability you do not use is pure liability. ITMS-90683, purpose strings you did not ask for.

Where it sits

shipcheck lists the native packages in your tree with their versions and maintenance status, so the audit is a report rather than an afternoon. It cannot run Apple's static analysis for them, and it says so rather than implying otherwise. What it checks. · After a rejection.

Questions and answers