Guide · App Review Guidelines
Guideline 2.5.19, explained
Apple gave hidden, dormant and undocumented features their own guideline on 16 October 2026. Here is the exact text, what changed, and what it means for apps that use feature flags or remote config.
By Claudiu Micu · Updated
The exact text
2.5.19 sits under Performance › Software Requirements. It has two sentences:
“Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review.”
“Attempting to hide undocumented features in your app binary, such as through code obfuscation or other methods, is grounds for removal of your app from the App Store and termination of your developer account.”
What changed on 16 October 2026
The rule itself isn’t new. Apple’s news post about the update describes it like this:
“2.5.19: New guideline clarifies long-standing policy on hidden, dormant, or undocumented features, formerly covered in Guideline 2.3.1.”
So the policy moved to its own number. If you have an older rejection that cites 2.3.1 for hidden features, the same reasoning now appears under 2.5.19.
How it fits with 2.3.1(a)
2.5.19 says what not to do: hide functionality. 2.3.1(a) says where to disclose it instead, and how specific to be:
“All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.”
Read together: anything your app can do should be reachable or described for the reviewer, and the place to describe it is the Notes for Review field in App Store Connect.
Are feature flags and remote config allowed?
The guideline text doesn’t mention feature flags, remote config or A/B tests by name. What it targets is functionality that is hidden, dormant or undocumented. A flag that can switch a feature on after approval is exactly the kind of thing a reviewer can’t see unless you tell them, so the practical answer is to document it.
Downloading code is a separate rule. Turning on code that is already in the reviewed binary is a disclosure question; downloading code that adds or changes features falls under 2.5.2, which says apps may not:
“download, install, or execute code which introduces or changes features or functionality of the app, including other apps.”
Apple also treats hiding features as a fraud signal
Apple’s page on review status lists examples of conduct App Review investigates, and says an investigation can extend a submission’s review. One example:
“Manipulation of the App Store experience, including gaming charts, search results, reviews, or referrals, or attempting to hide features in review. (Guidelines 2.3.1(a) and 5.6.3)”
What to write in your Notes for Review
- Every remotely controlled feature: what it does, its state during review (on, off, or depends on a rule) and the exact path to reach it.
- Staged rollouts and A/B tests: which group the review account lands in, or that every variant is complete.
- Paywall or pricing experiments: confirm every in-app purchase is visible in each variant.
- Developer, QA and staging switches: say they are off in this build and not reachable by users.
- A demo account (or a note that no login is needed) and a contact.
“The Notes field can contain up to 4000 bytes. You can write notes in any language.”
Sources
- App Review Guidelines · Apple Developer · “Last Updated: October 16, 2026”
- Updated App Review Guidelines are now available · Apple Developer News · October 16, 2026
- Track a submission’s review status · Apple Developer · App Review Help
- App Store Connect Help: App Review information · Apple Developer
Quotes checked on 27 October 2026. Apple and vendors change these pages, so read the current version before you submit. ReviewNotes is not affiliated with Apple.