# Guideline 2.3.1 - Accurate Metadata: Hidden Features Not Disclosed

**Guideline:** 2.3.1 · **Store:** Apple App Store · **Severity:** high · **Fix difficulty:** medium · **Typical turnaround:** 1-3 days

Canonical URL: https://appstorereject.com/rejections/apple/2/guideline-231-accurate-metadata-hidden-features-not-disclosed

## Description

Apple is rejecting your app because it includes features or functionality that were not disclosed in the review notes or are not immediately visible during review. This is Apple's 'no surprises' rule. They want to see everything the app can do, and they get suspicious when features are hidden behind gestures, deep links, server-side flags, or time-delayed activation. This rejection is particularly common for apps that use feature flags, server-side configuration, A/B testing, or delayed feature activation. If Apple discovers a feature they weren't told about, they treat it as a trust violation. This is also triggered when apps have hidden Easter eggs, secret menus accessible through specific gestures, or features that only activate after a certain number of uses. The key insight is that Apple wants a complete feature inventory in your review notes for any non-obvious functionality. If your app has a feature that requires specific conditions to trigger, you must document how to access it and why it exists.

## Common variations

- App includes hidden features not disclosed in review notes
- App contains functionality not visible during standard review
- Features are gated behind server-side flags not accessible to reviewers
- App appears to have different behavior than what was presented for review
- App contains undocumented features accessible through specific gestures or sequences

## Example rejection email

```
Guideline 2.3.1 - Performance - Accurate Metadata

We noticed that your app includes hidden features that were not disclosed in the app metadata or review notes. Specifically, the app includes functionality accessible through a gesture that was not documented for review.

All features and functionality of the app must be clearly disclosed in the Review Notes field and visible during review.

Next Steps:
Please provide complete information about all app features and functionality in the Review Notes field. Include instructions for accessing any features that are not immediately visible, along with an explanation of the feature's purpose.
```

## Resolution steps

## Quick Assessment
- **Risk level:** High (trust violation -- Apple may scrutinize future submissions more closely)
- **Resolution path:** Full disclosure and resubmit
- **Typical turnaround:** 1-3 days

## The Fix

1. **Inventory every feature** -- List every feature in the app, including those behind feature flags, gestures, deep links, A/B tests, or server-side configuration. Be exhaustive.

2. **Enable all features for review** -- Turn on all feature flags for the review build. If a feature isn't ready for public release, don't include it in the binary at all.

3. **Write comprehensive review notes** -- For each non-obvious feature, document: how to access it, what it does, and why it exists. Include screenshots or a short video URL if the feature is complex.

4. **Remove deceptive patterns** -- If you were intentionally hiding features from Apple (e.g., showing different content to reviewers vs. users based on IP detection), remove this logic entirely. Apple detects this and it can lead to app removal.

5. **Document A/B tests** -- If you use A/B testing, note this in review notes and explain what variations exist. Offer to provide the reviewer with a specific variant if needed.

## Prevention
- Always compile a feature inventory before submission
- Never ship feature-flagged code that's hidden from Apple -- if it's in the binary, disclose it
- Include a 'Feature Guide for App Review' section in your Review Notes for every submission
- Never detect Apple's review environment to change app behavior

## Appeal guidance

If the feature Apple found is benign (e.g., an Easter egg or developer credit screen), explain it transparently in the Resolution Center. If you used feature flags that were off during review, this is a serious trust issue -- be honest about the feature's purpose and commit to keeping it visible during future reviews.

## Before / after examples

**Before:** App has a crypto wallet feature gated behind a feature flag set to off during review, enabled for all users after approval
**After:** Crypto wallet feature either disclosed in review notes with instructions to access it, or removed from the binary entirely until ready for public review
**Why it works:** If it's in the binary, Apple needs to know about it. There's no such thing as a 'hidden' feature in Apple's eyes.

## Common questions

**Can you appeal a 2.3.1 rejection?**

If the feature Apple found is benign (e.g., an Easter egg or developer credit screen), explain it transparently in the Resolution Center. If you used feature flags that were off during review, this is a serious trust issue -- be honest about the feature's purpose and commit to keeping it visible during future reviews.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-231-accurate-metadata-hidden-features-not-disclosed*