On October 16, 2026 Apple published a revised set of App Review Guidelines. The headline change is a new Guideline 2.5.19 that pulls the hidden-feature rule out of 2.3.1 and states the consequence in plainer language; the same release clarifies 1.2 so that nonconsensual intimate imagery generated by AI is explicitly covered, adds a brand-new 2.3.14 on creative assets, and tightens Section 5 so that an app removed for facilitating trafficking or child exploitation is also blocked from alternative distribution. Apple's own announcement is here, with the change list in a separate news post.

Most of the questions we received in the first 48 hours were not about the new wording itself, but about scope: which apps are caught, and what has to change before the next binary goes up. These are the eight answers that matter for a normal commercial app and for a small portfolio of apps.

1. What exactly changed on October 16?

Four substantive edits, plus documentation links:

Two smaller edits: 3.1.1(a) drops the separate Music Streaming Services Entitlements bullet (folded into StoreKit External Purchase Link Entitlements) and clarifies that a link may point to a permitted destination; and Before You Submit / After You Submit gained documentation links. Apple says translations of the revised guidelines will appear on the developer site within one month.

2. Is 2.5.19 a new rule, or the same rule in a new place?

Both. The prohibition is long-standing — the same sentence used to sit in 2.3.1, which is still about accurate metadata and review notes. What changed is the packaging and the stated penalty: a dedicated number that reviewers can cite on its own, and an explicit statement that obfuscating undocumented features in the binary is grounds for removal of the app and termination of the developer account. If you have an internal review checklist keyed to guideline numbers, add 2.5.19 and keep 2.3.1 for metadata accuracy — they now operate independently.

3. What counts as bait-and-switch in practice?

Apple describes the pattern in its announcement as an app that misrepresents its purpose during review and reveals harmful capability only after approval. In guideline terms the behaviour appears in three places, and each one is independently enough for removal:

The practical test is not "did the binary change" but "did the app do something after approval that the reviewer could not have seen or tried during review". That includes a second build pushed later with a new capability and a generic release note, not only a same-build switch.

4. Does this affect server-side flags, remote config, and staged rollouts?

The guideline does not prohibit remote configuration, A/B tests or staged rollouts. What it targets is undisclosed functionality: an app whose real capability is unlocked by a server flag that the reviewer never sees and that the review notes never mention. If a flag can turn on something a reviewer would need to test — a different content category, a paid surface, a chat or generation feature, a second app inside the app — describe it in Notes for Review and, where possible, provide a test path. Two practical consequences: keep the flag inventory next to the release checklist, and treat any "enable it after approval" ticket as a compliance decision rather than a growth experiment.

5. What does the 1.2 clarification require from AI content apps?

The four baseline duties in 1.2 are unchanged and now explicitly cover AI content creation apps alongside social and UGC platforms:

The new element is the explicit naming of nonconsensual intimate imagery, including AI-generated imagery, as content that must be proactively prevented and removed. Apple also warns that failing to implement safeguards, or not remediating violations after notice, can violate the Developer Code of Conduct. For a generative app this means an input-side policy (blocking prompts and uploads aimed at real, identifiable people) and an output-side policy (detection, takedown, and a report path that a human actually works). A report button alone, with no response loop, is the failure mode Apple is describing.

6. What does the new 2.3.14 creative assets rule allow?

Creative assets are the image and video assets that can now appear in the product page header and in search results. 2.3.14 requires that they pertain to the app's content and functionality or its overarching brand, follow the standard metadata rules, and be appropriate for all audiences. It explicitly rules out inappropriate content, references to other apps with intent to mislead, unverifiable product claims, and specific or discounted pricing information. In practice: no competitor screenshots, no "as seen in" badges you cannot substantiate, no "50% off this week" in an asset, and no creative that promises a feature the current build does not ship.

7. What are the penalties, and do live apps get re-reviewed?

Apple's wording moves in two steps. Removal from the App Store is the first consequence for the app; the Developer Code of Conduct route and 2.3.1(b) cover egregious or repeated behaviour, which reaches the developer account. For trafficking and child exploitation, Section 5 adds a block from alternative distribution on top of App Store removal. Nothing in the announcement describes a mass re-review of the existing catalogue — but app review is a point-in-time judgement that can be revisited on any update, and the guidelines apply to apps already live. A dormant feature that has been sitting behind a flag for a year is not protected by the fact that the reviewers missed it once.

8. What should I check before the next submission?

  1. Feature inventory — list every user-visible capability in the build and confirm each one is described specifically in Notes for Review.
  2. Flag and remote-config audit — find every switch that can change what the app does, and decide for each whether it must be disclosed.
  3. Dormant code — remove or disable code paths that ship but cannot be reached in the submitted build, particularly anything copied from another project.
  4. UGC and AI moderation stack — filter, report, block, contact — and a written response process with an owner.
  5. Creative assets — check headers and search assets under 2.3.14 for other-app references, unverifiable claims and pricing.
  6. Agreements — the Apple Developer Program License Agreement was also updated on October 13, 2026; sign in and accept it, or account actions can stall.

None of this is exotic. The pattern across the last two years is consistent: Apple is less interested in the specific feature than in whether the review package told the truth about it. An app that documents what it does, and ships only what it documented, has very little to fear from 2.5.19.

Sources