Apple 2.5.19 + 2.3.14 Pre-Submit Checklist (Oct 2026)

2026-10-25 · Policy Insights

On October 16, 2026 Apple shipped App Review Guidelines v22, adding standalone 2.5.19 (hidden / dormant / undocumented features) and 2.3.14 (creative assets on product-page and search surfaces). Our earlier brief is a clause-level inventory of every substantive Add / Delete / Modify. This twin is the actionable pre-submit checklist — what to verify in App Store Connect and what to paste into Notes for Review before you hit Submit.

Education only — not legal advice. Grounded in Apple Developer News (Oct 16, 2026) and the live Guidelines wording summarized in the inventory article.

Why this twin exists

Clause	What moved (Oct 16)	Pre-submit risk
2.5.19 (new; formerly under 2.3.1)	Hidden / dormant / undocumented features must not ship. Functionality must be clear to end users and App Review. Hiding capabilities in the binary (e.g. via obfuscation or similar methods) is grounds for Store removal and developer-account termination. Companion News restates bait-and-switch enforcement here.	Debug menus, post-review feature flags, “reviewer mode,” and remote unlocks that change the product after approval.
2.3.14 (new)	Creative assets — product-page header, search creatives, and similar surfaces beyond app-in-use screenshots / preview videos — must relate to the app’s content, functionality, or brand; follow standard metadata rules; be appropriate for all audiences. Must not include inappropriate content, misleading references to other apps, unverifiable claims, or specific / discounted pricing.	First three frames of headers / search creatives; ASA creatives that leak pricing or competitor digs.

2.3.1 still covers Notes for Review and misleading marketing — keep that path honest even after the hidden-feature sentence moved to 2.5.19.

2.5.19 — Binary honesty checklist

Run this against the exact build you will submit (not “staging,” not “next week’s flag flip”).

Binary matches what Review will see

☐ No hidden, dormant, or undocumented features in the binary.
☐ Every user-reachable flow is either visible in the UI or documented in Notes for Review (with demo account / steps).
☐ “Reviewer mode,” god menus, QA overlays, and internal tools are off or removed from the release candidate — not merely gated behind an obscure gesture.
☐ Code obfuscation (or similar) is not used to conceal capabilities from App Review. Legitimate IP protection is fine; concealment of features is the account-level risk under 2.5.19.
☐ The marketing description, screenshots, and in-app experience tell the same product story (no bait-and-switch).

Feature flags / remote config (post-review risk)

☐ Feature flags that unlock new capabilities after approval are treated as new features — plan a review submission, not a silent remote enable.
☐ Bug-fix-only remotes (crash patches, copy typos, performance) stay within the spirit of Apple’s Bug Fix Submission path called out under After You Submit in the Oct 16 Guidelines. If a change would alter product behavior enough that Review would expect to re-evaluate it, submit for review instead of shipping OTA.
☐ Server-driven UI that can turn on an undocumented flow for a cohort is documented (or disabled) for the build under review.
☐ Kill-switches that disable a broken feature are safer than kill-switches that enable an undocumented one.

Source honesty note: Apple’s Oct 16 News and Guidelines harden 2.5.19 against hidden/dormant features and bait-and-switch; they also list Bug Fix Submission help under After You Submit. Apple does not, in those two News posts alone, publish a one-line “OTA bugfix is always OK” rule. Treat remote bug fixes as a narrow, non-product-change path — and when in doubt, submit.

Associated-account / termination awareness

☐ Teams share a clear internal rule: obfuscation-to-hide and bait-and-switch are account risks, not “just another 2.x rejection.”
☐ If you already received a related rejection, fix the binary and the Notes — a metadata-only resubmit will not clear 2.5.19.

2.3.14 — Creative assets checklist (first three frames)

Apply to product-page headers, search creatives, and similar App Store Connect creative surfaces (not only classic screenshots / preview videos).

Content & brand

☐ Creative pertains to this app’s content, functionality, or overarching brand.
☐ Appropriate for all audiences (assume kids can see search results).
☐ Follows the same metadata honesty bar as screenshots (see also 2.3.3 help on showing the app in use).

Hard nos (policy surface)

☐ No specific or discounted pricing (“$0.99,” “50% off,” “free this week”) on headers / search creatives.
☐ No unverifiable product claims (“#1,” “guaranteed,” uncited rankings).
☐ No references to other apps / platforms intended to mislead (competitor digs, “better than X,” store-hopping CTAs).
☐ No inappropriate content.

First-three-frames drill (do this literally)

Open the header / search creative as Review and users will see it — muted if needed — and pause on frames 1, 2, and 3:

Frame 1 — Does it show this app (or clear brand), not a competitor or unrelated promo?
Frame 2 — Any price, discount, or “limited offer” text? Strip it.
Frame 3 — Any unverifiable claim or other-app jab? Strip it.

If ASA or Custom Product Pages reuse the same assets, run the same three-frame pass before the next metadata push.

Notes for Review — paste-ready template

Keep Notes short, factual, and aligned with the binary. Replace bracketed fields.

English template

Notes for Review — [App Name] [version / build]

1) Demo access
- Apple ID / username: [demo@example.com]
- Password: [••••••••]
- Any 2FA / OTP: [how to obtain, or “none”]
- Region / storefront if relevant: [e.g. US]

2) How to reach primary flows
- On launch, tap [A] → [B] to open [core feature].
- Subscription / IAP sandbox: use the demo account above; restore purchases via [path].
- If content is account-gated, seed data is preloaded on this account.

3) Feature flags / remote config (Guideline 2.5.19)
- The submitted binary does not hide dormant or undocumented features.
- Remote config in this build is limited to: [list — e.g. copy, crash kill-switch].
- No post-approval flag is planned that would unlock new user-facing capabilities without a new submission.
- Internal / debug menus: [removed | disabled for App Store builds].

4) Creative assets (Guideline 2.3.14)
- Product-page header and search creatives show [app / brand only].
- They do not include pricing, discounts, unverifiable claims, or references to other apps.

5) Regulated / special docs (if any)
- [Attach or link what Before You Submit requires — e.g. licenses]

Contact for App Review questions: [name, email, timezone]

中文模板（可与英文同贴，或仅贴审核员可读的英文；双语团队常用双栏）

审核备注 — [应用名] [版本 / 构建号]

1) 演示账号
- Apple ID / 用户名：[demo@example.com]
- 密码：[••••••••]
- 二次验证 / OTP：[获取方式，或「无」]
- 相关店面 / 地区：[如有]

2) 主流程 steplist
- 启动后点击 [A] → [B] 进入 [核心功能]。
- 订阅 / IAP 沙盒：使用上述演示账号；恢复购买路径：[路径]。
- 若内容需登录，演示账号已预置数据。

3) 功能开关 / 远程配置（指南 2.5.19）
- 本次送审二进制不含隐藏、休眠或未说明功能。
- 本构建远程配置仅用于：[列举，如文案、崩溃熔断]。
- 不计划在未经新一轮审核的情况下，用开关解锁新的用户可见能力。
- 内部 / 调试菜单：[已移除 | App Store 构建已关闭]。

4) 创意素材（指南 2.3.14）
- 产品页页眉与搜索创意仅展示 [本应用 / 品牌]。
- 不含具体或折扣价格、无法核实卖点、或其他应用影射。

5) 监管 / 专项材料（如有）
- [按「提交前」要求附上]

审核联络人：[姓名、邮箱、时区]

Pre-submit run-of-show (15 minutes)

Install the release candidate on a clean device; walk the Notes steplist yourself.
Export / preview product-page header + search creatives → three-frame pass.
Paste the Notes template; delete unused sections.
Confirm the App Store Connect build number matches the Notes header.
Submit. If rejected on 2.5.19 / 2.3.14, fix the binary or creative, not only the reply text.

Soft next step (optional)

If a 2.5.19-style rejection or associated-account risk already landed, start from a compliance recovery path on your own Apple Developer account — see account recovery / verification and launch prep. KappS does not sell accounts or gray “代上架” shortcuts; we help with evidence-backed submissions on the client’s own console.

Sources as linked above. Policy education only — not legal advice. Last drafted 2026-10-25 (Asia/Singapore).

← Back to Policy Insights