App Review Guidelines, October 16, 2026: what changed and what to check

On October 16, 2026 Apple published an updated version of the App Review Guidelines, together with two posts: a list of changes and an explanation of why focused on nonconsensual intimate imagery and bait-and-switch apps. The update has no transition period: the guidelines page shows October 16 as its last update. Apple says translations will follow within a month.

We ship our own apps through App Review, so we read the new text clause by clause. Below is what changed, who it affects and what we would check before the next submission. Quotes and wording come from Apple's pages; where we give our own interpretation, we say so.

The changes at a glance

1.2: AI generators are user-generated content apps now

Guideline 1.2 used to speak about apps with user-generated content or social networking services. The new opening covers apps that let users "create, generate, upload, share, or otherwise contribute content" and names social media, user-generated content platforms and AI content creation apps directly. Nonconsensual intimate imagery now sits next to intellectual property infringement and anonymous bullying in the list of risks.

The required mechanisms are the same four as before:

• ✦a way to filter objectionable material before it is posted;
• ✦a way to report offensive content, with timely responses;
• ✦the ability to block abusive users;
• ✦published contact information.

The bigger change is about consequences. The text states that removing violating content is the developer's responsibility, and Apple added that failing to implement appropriate safeguards or to fix violations after notice may be treated as a breach of the Developer Code of Conduct. The guideline also describes the process: Apple asks you to remove the content and present a plan, the app may be pulled until you show improvements, and egregious or repeated cases lead to removal from the App Store and the Apple Developer Program.

Apple's explanatory post is blunt about the target: "nudification" apps that create sexually explicit images of real people without consent. Under the update, nonconsensual intimate imagery, including imagery made with AI tools, is content that apps must proactively prevent and remove.

In practice, if your app turns a prompt or a photo into an image, video or text that other people can see, treat it as a UGC app in review: build the filter, the report button and the block feature, and show them in the Review Notes.

2.5.19: hidden features and bait-and-switch

The rule against hidden, dormant or undocumented features used to live inside 2.3.1, the accurate metadata guideline. It now has its own number in the software requirements section. The functionality of an app must be clear to users and to App Review, and trying to hide undocumented features in the binary, for example through code obfuscation, is grounds for removing the app and terminating the developer account.

Apple's post describes the behavior it is after: an app that shows one thing during review and changes after approval, adding features that were not in the submitted version. Apple says such apps face removal from the App Store and from the Apple Developer Program. The post also gives the scale: last year Apple prevented over 150,000 apps with safety issues from reaching customers and terminated over 193,000 developer accounts for fraud and abuse.

Note what stays in 2.3.1(a): every new feature, functionality and product change must be described specifically in the Notes for Review, and generic descriptions are rejected.

The guideline doesn't mention remote configuration or feature flags, and they aren't banned. Our rule of thumb is simple: anything a flag can turn on must already be in the build that App Review sees, must be reachable during review and must be named in the Review Notes. A flag can hide an unfinished screen from users; it shouldn't hide a feature from the reviewer. Obfuscation is not forbidden either. The problem is using it to hide functionality.

2.3.14: creative assets have their own rule

On October 5 Apple added the product page header and the search results asset, which we covered in a separate article. At the time the content rules lived on the best practices page. Now they are guideline 2.3.14, so a violation is a regular rejection.

Creative assets must pertain to the app's content and functionality or its overall brand, follow the standard metadata guidelines and be appropriate for all audiences. They should not contain:

• ✦inappropriate content;
• ✦references to other apps with an intent to mislead;
• ✦unverifiable product claims;
• ✦specific or discounted pricing information.

If you check store metadata automatically, as we do with check scripts, add these four rules to them.

3.1.1(a): links to a permitted destination

The bullet on Music Streaming Services Entitlements is gone as a separate item and merged into the bullet on StoreKit External Purchase Link Entitlements. The text now speaks of a link to a "permitted destination" that informs users of other ways to buy digital goods or services, and notes that approved destinations may vary by region.

The rest of the bullet describes the same framework. The entitlements work only in specific storefronts and on certain platforms. In the United States storefront, apps may include buttons, external links and other calls to action without an entitlement. Everywhere else, apps and their metadata may not point customers to purchasing mechanisms other than in-app purchase. Misleading marketing, scams or fraud around the entitlement lead to removal from the App Store and possibly from the Apple Developer Program.

Section 5: trafficking and child exploitation

The introduction to section 5 already said that authorities are notified in extreme cases, such as apps that facilitate human trafficking or the exploitation of children. It now adds that such apps are removed from the App Store and blocked from alternative distribution. Apple's post notes that the prohibition itself is not new; the update makes the consequences explicit.

Small but useful: links before and after submission

Both the Before You Submit and After You Submit sections got links to additional documentation. Among the App Review help pages linked there now: testing on compatible devices, configuring in-app purchases for review, providing complete review information and regulatory documentation, tracking review status, requesting expedited review, contacting App Review, appeals and bug fix submissions. If your team has an internal release checklist, these pages are worth linking from it.

Checklist before the next submission

• ✦If users can generate or upload content in your app, including through AI, check for a filter, reporting, blocking and published contact information, and describe them in the Review Notes.
• ✦For generative features, make sure the app actively prevents and removes nonconsensual intimate imagery.
• ✦Make sure every feature behind a remote flag is in the reviewed build, reachable for the reviewer and described in the Review Notes.
• ✦Don't use obfuscation to hide functionality from App Review.
• ✦Check creative assets against 2.3.14: no prices or discounts, no unverifiable claims, no misleading references to other apps, suitable for all audiences.
• ✦If you use external purchase links, re-read 3.1.1(a) for your storefronts and check that the link leads to a permitted destination.
• ✦Bookmark the new help links from Before You Submit and After You Submit in your release checklist.