"Legal" is the wrong frame here, and the distinction matters. The question is really whether Apple allows hidden features, and the answer is a firm no: Guideline 2.3.1 prohibits hidden, dormant, or undocumented functionality, and shipping it risks not just rejection but removal and account termination. There is a real legal edge too, since hidden features that deceive users or regulators can cross into fraud. But for most developers the binding rule is the App Store policy. Here is what counts as hidden, why it is banned, and how it differs from a legitimate feature flag.
Short answer
No, hidden features are not allowed under the App Store rules. Guideline 2.3.1 states that apps must not contain hidden, dormant, or undocumented features, and that your app's functionality should be clear to both end users and App Review. Per Apple's accurate metadata guideline, concealing functionality from review, or enabling different behavior after approval, is a serious violation that can lead to removal from the App Store and termination of your developer account. This is separate from ordinary feature flags used for staged rollouts, which are acceptable when the functionality is still disclosed to review. Beyond Apple's rules, hidden features that deceive users can also carry real legal risk.
What you should know
- Hidden features are banned: Guideline 2.3.1 prohibits hidden, dormant, or undocumented functionality.
- Review must see everything: your app's full functionality must be clear to App Review.
- Post-approval changes count: revealing hidden behavior after approval is a serious violation.
- Consequences are severe: removal from the store and developer account termination.
- Feature flags differ: staged rollouts are fine when the functionality is disclosed.
What counts as a hidden feature?
Any functionality your app conceals from App Review or from users. That includes code paths that stay dormant during review and activate later, behavior gated behind a secret gesture or undocumented trigger, and content that switches to something different once the app is approved. The defining trait is concealment: the reviewer cannot see what the app actually does, so the approval does not reflect the real product. Classic examples are an app that presents a benign interface to review and later reveals gambling or other restricted content, or a build that points at one backend during review and a different one in production. If review could not observe a capability, and you intended it that way, it is a hidden feature under 2.3.1.
Why does Apple prohibit them?
Because review only works if it can see the whole app. App Review approves an app based on what it can observe, so any functionality concealed from the reviewer makes the approval meaningless and undermines the trust the store depends on. Hidden features are also how genuinely harmful behavior sneaks in, which is why Apple treats them as a serious violation rather than a minor metadata slip. The rule extends to changes after approval: using a remote switch to turn on functionality the reviewer never saw is treated the same as hiding it during review, because the effect is identical. The store's promise to users is that an approved app does what it appears to do, and hidden features break that promise.
Feature flags versus hidden features
The line is disclosure, not the mechanism. The table contrasts them.
| Practice | Allowed? | Why |
|---|---|---|
| Feature flag for a staged rollout of disclosed functionality | Yes | Review can still see the feature; you control timing |
| Server-driven content within the app's reviewed purpose | Yes | The capability and its scope were visible to review |
| Dormant code that activates a new purpose after approval | No | Concealed from review; violates 2.3.1 |
| Different backend or content shown only to reviewers | No | The reviewed app is not the shipped app |
So a feature flag is fine when the functionality it controls was disclosed and is consistent with what review saw; it becomes a hidden feature when it conceals a capability or changes the app's purpose behind the reviewer's back. The mechanism of a remote switch is neutral; using it to deceive review is what crosses the line.
What to watch out for
The first trap is assuming a remote config that flips behavior post-approval is safe because the binary passed review; if it reveals undisclosed functionality, it violates 2.3.1. The second is showing reviewers a different experience than users get, which is the same violation viewed from the other side. The third is treating a hidden feature as a clever shortcut, when the downside is account termination, not just a rejection. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces the endpoints and code paths in your build, which helps you confirm the app does not contain undisclosed remote behavior before you submit. Keeping functionality disclosed is the design discipline that keeps you on the right side of the rule.
What to take away
- Hidden features are not allowed; Guideline 2.3.1 prohibits hidden, dormant, or undocumented functionality.
- Your app's full functionality must be visible to App Review, and revealing concealed behavior after approval is the same violation.
- The consequences are severe, including removal from the App Store and developer account termination, and deceptive hidden features can carry real legal risk too.
- Feature flags for disclosed functionality are fine; use a pre-submission scan such as PTKD.com to confirm your build has no undisclosed remote behavior.
