What to Do When Apple 2.3.1 Hidden Features Are Rejected: A Practical Guide to Letting Reviewers Reproduce Features

Interpret Apple Review Guideline 2.3.1 on hidden features and provide actionable steps: for iOS developers and technical teams, clearly explain why a feature that clearly exists is still rejected, and give an inventory of entry points and trigger conditions, turn hidden entry points into reproducible paths, write out entry points and steps item by item in review notes, synchronize metadata and version notes, self-check before submission and prepare for appeals, with a checklist attached.

Problem introduction: the feature really exists, so why is it still rejected under 2.3.1?

The core requirement of Apple Review Guideline 2.3.1 (Hidden Features) is: the App must not contain hidden, dormant, or undocumented features, and the App's actual features must be clearly visible to users and the review team; all new features and product changes need to be specifically explained in the review notes in App Store Connect, and vague descriptions are likely to be directly rejected. Repeated or serious violations may lead to removal, or even termination of the developer account.

The actual situation for many teams is not that they "hid a feature," but rather that the feature really exists, only the reviewer cannot find the entry point, cannot see the trigger conditions clearly, and cannot reproduce it. This article is aimed at iOS developers and technical teams and provides step-by-step operations to make features transparent and verifiable by reviewers. It applies to submitting new versions for review and to remediation after being rejected under 2.3.1.

Step One: Inventory all entry points and trigger conditions

First make a complete feature list. Mark all entry points in the App in three categories: those users can directly see, those that appear only under specific conditions, and those that appear only under specific accounts or server switches. For each category, record four pieces of information: the entry path, the trigger prerequisites (login status, region, version number, remote configuration), whether a specific test account is required, and whether it is consistent with the online configuration.

Anything the reviewer cannot naturally reach in the ordinary flow counts as a "feature the reviewer cannot see" and needs additional explanation or adjustment. The value of this step is to turn "I think the feature is very obvious" into "I can write steps that the reviewer can follow and see it." If you yourself follow the notes along a certain path and it fails, then it must be fixed before submission.

Step Two: Turn hidden entry points into reproducible paths

For features that must be retained but are hidden by default (for example, content open only to specific users), provide a channel the reviewer can use. There are two common approaches: first, provide a stable test account in the review notes and ensure that in the build submitted for review this account can directly see the feature being questioned; second, without affecting normal users, provide a review-only demo entry point, but the trigger method must be clearly written in the review notes.

The core principle is just one sentence: when the reviewer follows the steps you wrote, they must be able to see the feature itself in one go, without guessing and without trial and error. Two common pitfalls should be avoided here: writing the test account in a screenshot but not writing the login method; and only saying "visible after login" without explaining which environment the login account comes from (production or test server).

Step Three: Write out the features item by item in the review notes

The review notes are not a restatement of the App introduction, but an "operation manual" for the reviewer. It is recommended to write them item by item according to feature, with each item including: feature name, entry location, operation steps, result seen, and related test account. Examples are as follows:

功能：会员专属内容
入口：底部“我的” → “会员中心” → “专属内容”
前提：使用备注中提供的测试账号登录
步骤：1. 打开App；2. 用测试账号登录；3. 进入会员中心；4. 点击“专属内容”
结果：展示会员专属列表，可正常播放
说明：该功能对普通用户默认折叠，仅会员可见，非隐藏功能

If a feature depends on a remote switch or staged rollout, please ensure that the relevant switch is turned on in the build during review and explain this in the notes. The accounts, paths, and switches mentioned in the notes must be consistent with the submitted build; otherwise, if the reviewer fails when following the steps, it may still be judged as a hidden feature.

It is also recommended: use a numbered list in the notes rather than a whole paragraph of text; when there are many features, arrange them in the order the reviewer is likely to question them, and put the features most easily misjudged as hidden at the very front.

Step Four: Synchronously update metadata and in-App copy

Reviewers will also compare the description on the App Store page with the actual features. If a feature has been explained in the review notes, but the App Store description, screenshots, or version notes do not mention it at all, it is easy to be considered "undocumented." It is recommended to briefly list the features added or changed in this version in the version notes, and update screenshots where necessary, so that the metadata is consistent with the actual state in the App.

Note: what metadata updates is the "visible explanation of this change," not a pile of marketing copy. If the description does not match the actual features, that itself may lead to new problems.

Step Five: Self-check before submission and prepare for appeals

If you have already been rejected, first check against the clause given in the rejection notice: is the entry point invisible, are the notes not specific, or is the feature not reflected in the metadata. After modifying according to the reason, you can explain the adjustments made in the appeal and attach operation instructions that allow the reviewer to reproduce. Note: do not try to bypass review through hidden switches, and do not temporarily disable features during review; these practices may worsen the handling.

Checklist

• Have all features that require specific conditions to trigger been listed?
• Do the review notes clearly state the entry point, steps, result, and test account item by item according to feature?
• Are the accounts and switches mentioned in the notes actually available in the submitted build?
• Do the App Store description and version notes cover the newly added or changed features?
• After rejection, did you check and revise item by item against the reasons for rejection?

Making features transparent and visible to reviewers is the core of 2.3.1 compliance. Following the above steps can reduce repeated rejections caused by "invisibility".