App Store Guideline 2.5.19 explained: Hidden, dormant, or undocumented features

Everything your app can do should be clear to users and to App Review. A feature that is in the binary but switched off during review, unlocked by a hidden gesture, or reachable only through an undocumented URL scheme is what this rule targets.

Obfuscation is not banned by itself. Protecting your implementation is fine; using obfuscation or any other method to hide functionality from review is what Apple calls out.

2.5.19 is one of the guidelines that also apply to Notarization for iOS and iPadOS apps, so it covers apps distributed outside the App Store in the EU as well.

It works together with Guideline 2.3.1(a), which still requires every new feature, functionality, and product change to be described specifically in Notes for Review and to be accessible for review.

Whether the app behaves the same for the reviewer as it will for users after approval, with no feature kept dark until the review is over.

Whether every new feature is named in Notes for Review, with the steps, account, or hardware needed to reach it.

Whether the binary contains functionality that the app never presents, and whether anything is being concealed rather than simply protected.

A remote config or server flag that switches on a different experience after approval, such as a web view to a betting site, an external payment flow, or unrelated content.

Debug menus, admin panels, or test tools reachable in the release build through a hidden gesture, tap sequence, or URL scheme.

A feature that needs a code, account type, or region the reviewer was never given and that Notes for Review don't mention.

Code for an unreleased feature shipped in the build and turned on later without a new review.

Obfuscation or encryption used to keep functionality away from review.

List every feature behind a flag, remote config, or server switch. Either make it visible in the reviewed build or remove it from the binary.

For staged rollouts and A/B tests, describe the variants in Notes for Review and give the reviewer a way to see each one.

Remove debug menus, hidden settings, and internal tools from release builds, or exclude them at compile time so they are not in the binary.

If you obfuscate code for anti-tamper or IP protection, make sure it hides how features work, never that they exist, and be ready to explain it.

Ship significant new functionality through a reviewed update, not a server switch.

Rewrite Notes for Review feature by feature. "Bug fixes and improvements" is not enough when the update adds functionality.

Name the feature Apple flagged, say whether you removed it or made it visible, and give the exact path to reach it in the new build.

If the flagged behavior is legitimate (a staged rollout, a region-specific feature, an accessibility option), explain what it does, who sees it, and how the reviewer can turn it on.

Don't deny functionality that is in the binary. 2.5.19 ties hidden features to account termination, so a precise, verifiable answer matters more than a fast one.