Guideline 2.5.1: Private API use

Guideline 2.5.1 - Performance - Software Requirements

Your app uses or references the following non-public or deprecated
APIs:

[framework 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 in the future. Please revise your app to remove these APIs
before resubmitting.

What it actually means

First, the jargon. An API is a way for your app to ask the phone to do something: show a keyboard, read a photo, play a sound. Apple publishes a huge official catalogue of these and promises they'll keep working; those are public APIs. But iOS also contains internal machinery Apple built for its own use and never promised to anyone. Those are private APIs: undocumented, unsupported, liable to change or vanish in any iOS update. Apps that call them can break overnight for every user at once, which is why Apple's rule says apps may only use public APIs.

The same guideline adds three siblings: your app must run on the current version of iOS, must phase out deprecated technology (old features Apple has marked for retirement), and must use frameworks for their intended purpose; Apple's own examples are that HomeKit is for home automation and HealthKit is for health and fitness, not whatever else they might be bent into.

This rejection is automated. A scanner reads your app's compiled code, matches it against a list of forbidden calls, and names what it found. The good news: it names what it found. The fix is unusually concrete.

Why AI-built apps hit this

You didn't call a private API; you can't even read the code. But your app is mostly other people's code: packages and plugins your AI tool pulled in to solve problems, sometimes chosen from old forum answers in its training data. Some of those packages reach for private APIs as a shortcut, or simply haven't been updated since the technique was tolerated. A snippet pasted from a 2019 Stack Overflow answer into your tool's context can carry a forbidden call straight into your build.

Deprecated-technology flags work the same way: an AI tool can confidently generate code against a framework Apple retired years ago, because that framework is well represented in what it learned from. Either way the scanner doesn't care about intent: the call is in the binary, so the rejection fires.

How to fix it

1. Copy the exact names from the rejection. Apple lists the specific APIs, frameworks, or symbols it found. Those names are the entire puzzle, so don't paraphrase them, copy them.
2. Paste them to your AI tool and ask where they come from. Something like: "Apple rejected the app under guideline 2.5.1 for using these non-public or deprecated APIs: [paste list]. Which dependency or file in this project uses them?" The tool can search the project for you.
3. Ask for removal or replacement. If a package you don't really need is responsible, have the tool remove it. If it's load-bearing, ask the tool to update it to its latest version (maintainers usually strip private API calls once Apple starts flagging them) or to swap in a supported alternative that uses public APIs.
4. Confirm the names are gone. Ask the tool to search the whole project, including dependencies, for each flagged name and confirm zero matches before you rebuild.
5. Resubmit with a note. Briefly say which dependency contained the flagged APIs and that it was removed or updated. It tells the reviewer the finding was understood, not ignored.

What to write in Resolution Center

Adapt this to what you actually changed; don't send it unmodified:

Hello,

Thank you for identifying the non-public API references. We've traced
them and resolved the issue:

- The flagged APIs ([names from the rejection]) came from the
  third-party dependency [package name], not from our own code
- We have [removed that dependency / updated it to version X, which no
  longer references these APIs]
- We've verified the flagged names no longer appear anywhere in the
  project

The new build ([build number]) contains these changes. We'd appreciate
a second look.

Thank you,
[Your name]

How to avoid it next time

Be conservative about what goes into your app. When your AI tool proposes adding a package, ask whether it's actively maintained and App Store-safe, and prefer well-known, recently updated libraries over whatever an old forum thread recommended. Before each submission, ask the tool to update dependencies and flag any that are abandoned; stale packages are where private API calls and deprecated frameworks hide. And keep building against current iOS: the further behind you fall, the more of yesterday's acceptable tricks become today's flags.

Related guides: 2.1: App completeness (the other Performance rejection, for apps that crash or ship unfinished) and 4.2: Minimum functionality (apps that run fine but don't do enough).