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

Canonical page: https://acceptmy.app/guidelines/2-5-19-hidden-dormant-and-undocumented-features

Guideline 2.5.19 was added in Apple's October 16, 2026 revision, but the rule is not new: the ban on hidden, dormant, or undocumented features used to open Guideline 2.3.1. Apple moved it into Software Requirements and added a sentence about the binary itself. Trying to hide undocumented features in your app binary, for example through code obfuscation, is grounds for removal from the App Store and termination of your developer account.

## What this guideline means in practice

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.

- [Guideline 2.3.1: Review notes and misleading marketing](https://acceptmy.app/guidelines/2-3-1-accurate-metadata-requirement.md)

## What Apple is likely checking

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.

## Common rejection triggers

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.

## Fix checklist before resubmission

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.

## Reviewer reply angle

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.

## Apple guideline references

Guideline 2.5.19


## Related pages
- [App Store Guideline 2.3.1 explained: Review notes and misleading marketing](https://acceptmy.app/guidelines/2-3-1-accurate-metadata-requirement.md)
- [App Completeness: what Apple expects before review](https://acceptmy.app/guidelines/2-1-app-completeness.md)
- [App Store Guideline 2.5.2 explained: Self-contained app bundles](https://acceptmy.app/guidelines/2-5-2-self-contained-app-bundles.md)
- [Guideline 2.1 Information Needed: what to send Apple](https://acceptmy.app/rejections/guideline-2-1-information-needed.md)

Last updated: 2026-10-17