Guideline 2.3.1: Hidden or undocumented features

Guideline 2.3.1 - Performance - Accurate Metadata

We discovered that your app contains hidden or undocumented features.
Your app's functionality should be clear to end users and App Review.

Apps should not include any hidden, dormant, or undocumented features,
and all new features, functionality, and product changes must be
described with specificity in the Notes for Review section of App
Store Connect.

Next Steps

To resolve this issue, please remove or fully document these features.
If they are intended for your users, make them accessible for review
and describe them in your review notes.

What it actually means

Apple found something in your app that a normal user, or the reviewer, can't see or wasn't told about. The guideline bans "hidden, dormant, or undocumented features": anything switched off, tucked behind a secret gesture, or waiting to activate after the app is approved. It also covers misleading marketing: promoting things the app doesn't actually do, or advertising a false price.

Take this one seriously. Most rejections are routine back-and-forth; 2.3.1 is not. Apple's own text says egregious or repeated behavior is grounds for removal from the Apple Developer Program, meaning your developer account, not just this app. The guideline ends with "if you're dishonest, we don't want to do business with you." Reviewers apply it accordingly, even when the hidden thing got there by accident.

The fix is transparency in both directions: nothing in the build the reviewer can't reach, and nothing in your marketing the build can't do.

Why AI-built apps hit this

You almost certainly didn't set out to hide anything, but your AI tool may have. Tools like Lovable, Bolt, and Cursor routinely scaffold extras you never asked to ship: an admin panel, a debug menu, a "coming soon" screen, a feature flag that disables a half-built idea from three weeks ago. You see the screens you tested. The reviewer decompiles nothing and suspects everything: a settings toggle that does nothing visible, or a route that only opens for a special account, reads as a feature you're concealing until after approval.

The other trap is the Notes for Review field itself. Apple now requires new features to be "described with specificity" there, and says generic descriptions will be rejected. Founders often leave it blank or paste their marketing blurb; either can trigger this rejection on its own.

How to fix it

1. Get a full inventory of what's in the build. Ask your AI tool directly: "List every screen, hidden route, admin view, debug menu, feature flag, and disabled feature in this app." Read the list as a reviewer would; anything you don't recognise is the problem.
2. Remove what users shouldn't have. Tell your tool to delete, not just hide, admin panels, debug menus, test screens, and any feature that's off behind a flag. If it's off, it shouldn't ship. Rebuild and confirm those screens are gone.
3. Document what stays. In App Store Connect, open your app's version page and find App Review Information → Notes. Describe every feature specifically: what it does, where it is, how to reach it. Generic notes get rejected, so name screens, not benefits.
4. Give the reviewer full access. If any feature needs an account or a paid tier, provide a working demo login in App Review Information and make sure it unlocks everything. A feature the reviewer can't reach counts as hidden.
5. Audit your marketing. Check your description, screenshots, website, and ads against what the app really does today. Remove any claim, feature or price, that the shipping build can't back up.

What to write in Resolution Center

Adapt this to what you actually found and changed; don't send it as-is:

Hello,

Thank you for the review. We've investigated and resolved this:

- The [feature/screen] flagged was [development scaffolding / an
  unfinished feature] left in the build unintentionally. It has been
  fully removed in version [X.X], not merely hidden.
- All remaining features are accessible to users and are now described
  specifically in the Notes for Review section.
- A demo account ([username]) is provided in App Review Information
  with access to every feature.

There was no intent to conceal functionality, and nothing in the app
activates after review. Happy to answer any questions.

Thank you,
[Your name]

How to avoid it next time

Before every submission, ask your AI tool the inventory question from step 1 and read the answer; it takes two minutes and catches the scaffolding you forgot existed. Make writing specific review notes part of your release routine, the same way you bump the version number. And never plan to "turn a feature on later" after approval: submit the app you intend users to get, then ship changes as a new version through review.

Related guides: 2.1: App completeness (the reviewer couldn't get the app working at all) and 2.3.7: Name, subtitle & keyword abuse (metadata that oversells or games the store).