How to Fix App Store Guideline 5.6 Hidden Features Rejection
Audit release-only paths, test hooks, feature flags, remote configuration, and reviewer access after Apple says functionality appears intentionally hidden.
Direct answer
Do not resubmit the same build, rename the suspected code path, or try to make it harder for review to find. Preserve the exact rejected archive, then audit every way the release can behave differently by account, purchase state, storefront, region, device, time, server response, remote flag, URL or launch argument. Remove test and debug unlocks from the distribution target, make every legitimate feature visible and specifically documented for App Review, and verify that the production backend gives reviewers the same product behavior as customers. If the exact reviewed build already has one consistent, fully disclosed behavior, reply with build-specific evidence and ask Apple to identify the screen or runtime condition at issue before filing an appeal.
Match the wording in your rejection
“Features appear to have been intentionally hidden during the review process”
Treat this as a behavior-difference investigation. Compare what the exact release can show or unlock across review accounts, ordinary customer accounts, purchase states, regions, devices, server responses, remote flags, deep links, launch arguments, and time-based conditions.
“Pattern of unusual behavior commonly associated with fraudulent activity”
Do not guess at Apple's internal signal or deny it in general terms. Build an auditable account of the submitted artifact, every conditional path, the production backend, and what changed before asking App Review to clarify the specific behavior.
The release contains a UI-test entitlement override, debug menu, demo unlock, mock purchase, or alternate environment
A path does not become harmless merely because ordinary users are unlikely to trigger it. Exclude test-only behavior from the App Store configuration and prove that access is granted only through the legitimate production flow.
The same rejection returns after a feature was disabled
Confirm that the feature, assets, routes, remote flag, server branch, deep link, cached state, and alternate account behavior are actually absent from the new archive and production environment. A hidden or disabled path can leave the underlying review concern unresolved.
What this rejection usually means
A Guideline 5.6 hidden-features rejection is not resolved by a more persuasive paragraph alone. Apple separately says in Guideline 2.3.1 that apps must not contain hidden, dormant, or undocumented features and that new functionality must be described specifically and made accessible for review. A release can look inconsistent even without reviewer-targeting code: test hooks may remain compiled into the app; a remote flag or backend rule may expose different screens; an account, purchase, region, date, device, deep link, or cached value may unlock another path; or Notes for Review may omit a legitimate but non-obvious capability. The recovery task is to prove what the exact rejected artifact and production environment can do, eliminate undisclosed alternate behavior, and give Apple a reproducible path through the product.
Likely rejection signals
- Release code still handles UI-test launch arguments, environment variables, test credentials, debug gestures, secret taps, or internal URL schemes
- A local boolean, keychain value, receipt shortcut, mock StoreKit state, or server response can grant paid or privileged access without the normal production verification path
- Remote configuration, feature flags, experiments, allowlists, IP or region rules, device checks, dates, or account roles change the app's core behavior
- The reviewer account sees empty, restricted, fallback, or materially different content from an ordinary eligible customer
- A WebView, downloaded catalog, backend-rendered screen, or remotely supplied asset can change after the binary is submitted
- A feature was hidden in navigation but remains reachable through a deep link, notification, widget, URL scheme, restored state, or server command
- Review Notes use generic wording and omit a new, conditional, paid, hardware-dependent, or otherwise non-obvious feature
- The team tested a Debug build or internal environment instead of the signed distribution configuration and production backend
Recovery plan
- Freeze speculative resubmissions. Preserve the complete rejection, reviewer attachments, submission date, app version, build number, review account, and the exact archive that produced the uploaded build. Record the production configuration and backend version that were active during review.
- Create a behavior-state matrix for the submitted release. Cover signed-out and signed-in users, new and old accounts, every role and entitlement, subscribed and unsubscribed states, restore purchases, storefront and region, device class, locale, permissions, dates, network failures, offline state, remote flags, experiments, deep links, notifications, widgets, and restored navigation.
- Audit the distribution target and its dependencies for test-only behavior. Review launch-argument handlers, URL schemes, hidden gestures, debug menus, demo unlocks, mock data, receipt or entitlement overrides, staging endpoints, internal accounts, environment switches, and code included only through Release build settings or third-party SDK configuration.
- Audit remotely controlled behavior separately. Inventory feature-flag providers, server allowlists, account and IP rules, remotely delivered navigation, WebView content, downloaded catalogs, experiments, and scheduled changes. Make sure review cannot receive a temporary or reduced product while customers receive another one.
- Classify each conditional path. Remove development and automation hooks from the App Store target; replace unsafe entitlement shortcuts with the real verified production state; delete dormant routes and assets that should not ship; and keep only legitimate customer-facing variation that is necessary, accurate, and reviewable.
- Make every retained non-obvious feature accessible to App Review. Provide a stable review account or approved demo mode, required sample data, hardware or QR resources, exact prerequisites, and numbered navigation. Apple says new functionality and product changes must be described with specificity in Notes for Review.
- Create a clean distribution archive and repeat the audit against that artifact, not only the source tree. Compare the rejected and corrected releases so you can show which handlers, flags, routes, assets, endpoints, or entitlements were removed or changed.
- Test the corrected release from a clean install on physical devices with the production backend. Exercise every row of the behavior-state matrix, including purchase and restore, account transitions, deep links, remote flags, denied permissions, offline recovery, and a reviewer-equivalent account on an external network.
- Prepare a short evidence package: build identifiers, before-and-after behavior table, distribution-target inventory, clean-install recording, relevant production logs, review-account steps, and specific Notes for Review. Remove secrets and personal data from every attachment.
- Choose the recovery path from the facts. Upload a new build when the binary or remotely controlled product behavior changed. Reply with clarification when the build was already consistent but the path or review information was incomplete. Appeal only after build-specific evidence still conflicts with Apple's finding.
Evidence to prepare
- Complete rejection text, guideline citation, reviewer attachments, review date, app version, build number, and submission ID
- Exact rejected archive plus the Release configuration, dependency lockfiles, entitlements, built property lists, embedded frameworks, extensions, and URL schemes
- Behavior-state matrix covering accounts, roles, purchases, regions, devices, dates, permissions, remote flags, backend responses, deep links, and restored state
- Inventory of test hooks, launch arguments, debug menus, demo modes, mock purchases, alternate environments, allowlists, and feature-flag rules
- Before-and-after artifact comparison tied to the corrected build, without unsupported claims about what Apple detected
- Clean-install recording of the production review path and time-correlated logs showing the reviewer-equivalent account and backend response
- Stable review credentials, representative sample data, required hardware or resources, and numbered Notes for Review
- A concise reply that names only completed changes and asks for the exact remaining screen or condition if the concern persists
Appeal or fix first?
Clarify first when the exact rejected build and production environment already present one consistent, fully disclosed behavior and you can support that claim with the archive audit, state matrix, clean-install recording, and production evidence. Ask App Review for the screen, timestamp, account state, or runtime condition that produced the finding. Appeal only if the same factual conclusion remains after that evidence and the appeal can explain why the reviewed artifact complied at the time of review.
Fix and resubmit when any test hook, entitlement bypass, debug or demo path, dormant route, remote flag, backend rule, account condition, region check, deep link, or downloaded content can expose undisclosed behavior. Also fix when legitimate functionality is not reliably accessible or the production environment gives App Review a materially different experience. Do not camouflage or rename the path; remove it from distribution or make the legitimate feature transparent and reviewable.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the exact app version, build number, and Guideline 5.6 or 2.3.1 wording you are addressing.
- State whether you found an alternate behavior path; describe only verified, completed changes in the submitted build and production environment.
- List the account, purchase, region, flag, backend, deep-link, and test-hook states you checked, then point to the attached evidence.
- Provide stable access and numbered steps for every legitimate non-obvious feature, including expected results.
- If no inconsistent behavior remains, ask Apple to identify the relevant screen, timestamp, account state, or runtime condition without speculating about internal detection systems.
Frequently asked questions
Why did Apple cite Guideline 5.6 when hidden features are described in 2.3.1?
Guideline 2.3.1 explicitly prohibits hidden, dormant, or undocumented features and requires specific Notes for Review. Guideline 5.6 addresses repeated manipulative, misleading, or fraudulent conduct. A rejection message can frame apparently hidden behavior as a broader trust or conduct concern, so the recovery should address both the concrete behavior and the accuracy of the review information.
Can an unused debug or UI-test hook cause a problem if normal users cannot see it?
Treat any alternate path compiled into the distribution build as a serious audit finding, especially if it changes purchases, entitlements, content, accounts, or core behavior. Remove test-only mechanisms from the App Store target rather than relying on the assumption that nobody will trigger them.
Should I delete all feature flags and remote configuration?
Not automatically. Inventory every flag and prove that it does not hide functionality from review or make the approved product materially different. Remove dormant, reviewer-specific, unsafe, or unreviewable paths and document legitimate conditional features precisely.
Can I resubmit the same build with better Notes for Review?
Only when the binary and production behavior are already consistent and the real problem is missing review information or access. Reply in the existing App Review thread with specific instructions first. If code, configuration, remotely delivered content, or backend behavior changed, submit the corrected build and identify it clearly.
When should I appeal a Guideline 5.6 hidden-features rejection?
Appeal after a release-specific audit shows one transparent behavior, clarification and evidence do not resolve the finding, and you can point to facts from the exact reviewed build. Do not appeal while an alternate path remains or while important states are still untested.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Apple App Review Guidelines — 2.3.1 and 5.6. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.