---
title: "Apple's Oct 16 Review Rules: AI Content and Hidden Features"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-10-18"
category: "How to Build"
tags:
  - Apple App Review Guidelines update
  - App Store Guideline 2.5.19
  - App Store Guideline 1.2
  - AI generated content moderation
  - App Store rejection
excerpt: "Apple updated its App Review Guidelines on October 16, 2026, tightening Guideline 1.2 on AI-generated intimate imagery and adding Guideline 2.5.19 on hidden or dormant features. Here is what changed, who is exposed, and what to audit this week."
reading_time: "10 min read"
canonical_url: "https://kanopylabs.com/blog/apple-app-review-guidelines-october-2026-ai-content-hidden-features"
---

# Apple's Oct 16 Review Rules: AI Content and Hidden Features

## What Apple Changed on October 16

Apple published an updated set of App Review Guidelines on October 16, 2026. The page now carries that date in its "Last Updated" line. Two changes matter for most founders, and one of them is a brand new rule.

The first is a clarification to **Guideline 1.2**, the user-generated content rule. Apple's release note says it clarified the app content and app types that fall under it. The text now explicitly covers nonconsensual intimate imagery, including imagery generated with AI tools. Apps that host or generate content are expected to prevent that material and remove it. Apps that lack appropriate safeguards, or that do not fix violations after notice, risk a Developer Code of Conduct violation and removal from the App Store. Apple also restated that pornographic material is prohibited, including so-called nudification apps that create sexually explicit images of real people without their consent.

The second is a new rule, **Guideline 2.5.19**. Apple describes it as a clarification of long-standing policy on hidden, dormant or undocumented features. That policy used to sit under Guideline 2.3.1. The target is the app that tells App Review one thing, gets approved, and then turns on something else after launch. The penalty for that is removal from the App Store, and for bait-and-switch cases, removal from the Apple Developer Program.

I read the summaries from several outlets and checked them against each other, but you should read the guidelines page itself before you act on any detail here. Apple's wording is what App Review applies.

![Hand holding a smartphone showing a grid of mobile apps](https://images.unsplash.com/photo-1512941937669-90a1b58e7e9c?w=800&q=80)

## Why Apple Is Doing This Now

This update did not come out of nowhere. Through 2026, reporters and regulators kept finding nudify apps on the App Store. A January report from the Tech Transparency Project found them widely available. An April report claimed that App Store search suggestions and ads were steering users toward them. In July, the San Francisco City Attorney sent cease-and-desist letters to Apple and Google. Of 13 apps the office investigated, eight were on the App Store. Apple said it removed three, was terminating those developer accounts, and was in contact with four others.

Apple has also said it blocked more than 150,000 apps over safety issues and terminated more than 193,000 developer accounts for fraud and abuse in the past year. Those figures come from secondary coverage of Apple's statements, so treat them as indicative. The direction is not in doubt. Apple is moving from reacting to individual apps to writing the expectation into the rulebook, so the next case can be handled by citing a rule number.

For a founder, the useful reading is this. Apple now has a written standard for AI-generated content and a written standard for features that appear after review. Both are easy to cite in a rejection or a removal notice. If your app touches either area, you want to be on the right side of them before App Review writes you a note.

## Which Apps Are Actually Exposed

Not every app needs to panic. The apps with real exposure fall into a few groups.

- **Apps that generate or edit images, video or avatars.** Face swap, photo editing, AI avatar tools, "make me look like" filters, and text-to-image features all count. If a user can upload a photo of another person and get an altered image back, you are in the zone Guideline 1.2 now describes.

- **Apps with user-generated content.** Social feeds, dating apps, community forums, chat, marketplaces with photo listings, and anything where one user can post something another user sees. Guideline 1.2 already applied here. The clarification makes AI-generated intimate imagery an explicit case.

- **Apps that ship dormant code.** Features that are built, hidden behind a flag, and switched on by a server response after review. This is normal engineering practice, and it is the group where I expect the most confusion about Guideline 2.5.19.

- **Apps with a thin wrapper around a third-party model.** If your app passes prompts to an image model and returns the result, you inherit whatever that model will produce. The vendor's filters help, but Apple holds you responsible for the app.

An accounting app, a scheduling tool, a field-service app or an internal B2B product with no image generation and no public posting is not the target. Check the list honestly, though. Plenty of apps have a profile photo upload and a comment box, and that is enough to put you under Guideline 1.2.

What Apple did not state is just as important. The update does not give a compliance deadline for existing apps, does not define what counts as an adequate proactive safeguard, and does not explain how Apple will detect behavior that changes on the server after approval. Expect those questions to be answered through individual review decisions, not documentation.

## Guideline 1.2 for AI Features: What Safeguards Look Like

Apple says apps must proactively prevent and remove this imagery. It does not say how. So the practical question is what a reviewer will accept as proof that you took it seriously. Based on how App Review has treated user-generated content for years, here is the set I would build for any app with image generation or photo upload.

### Block at the input

Run uploaded photos through a moderation check before they reach your generation model. The big vendors sell this as an API: image moderation endpoints from the major cloud providers and the model labs themselves, priced per image at fractions of a cent. Reject images that contain nudity when your product has no reason to accept them. For a photo editor, a blanket rule that explicit input is refused is simpler than a nuanced one.

### Block at the output

Run the generated result through the same check before the user sees it. Models drift, prompts get clever, and your input filter will miss things. An output filter is the safety net, and it is the part reviewers like to see because it is checkable. If you can show a test where an explicit result is blocked, you have a clean story.

### Give users a way to report, and act on it

Guideline 1.2 has long required a way to report offensive content and a way to block abusive users. Put the report button where the content is, not three screens deep in settings. Then actually staff it. A report queue nobody reads is the failure that turns a warning into a removal, because Apple's language covers developers who do not remedy violations after notice.

### Keep a takedown path that works in hours

You need to be able to delete a piece of content, and ban the account that made it, without a code deploy. That means an admin tool, even a crude one. If your only way to remove an image is for an engineer to run a database query, build the admin screen this month. Our guide on [AI content moderation](/blog/ai-content-moderation-guide) covers the architecture, and the cost article on building a moderation system gives realistic budgets.

![Analytics dashboard on a laptop showing moderation queue metrics](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

## Guideline 2.5.19: The Dormant Feature Problem

Here is where I see founders getting nervous, so let me be precise about what the rule is aimed at. Apple describes the target as apps that misrepresent their purpose during review and then reveal harmful capabilities after approval, such as adding features that were not in the version they submitted. The word that does the work is "harmful" together with "misrepresent." A feature flag for an unfinished screen is not that.

That said, the rule also names hidden, dormant and undocumented features as a category, and the text is not a safe harbor for sloppy practice. A few habits will keep you clear of trouble.

- **Describe what the app does in your review notes.** If a feature is gated by a server flag and you plan to enable it after approval, say so in the App Review notes, and give the reviewer a way to see it. A demo account with the flag on is the standard move.

- **Do not ship a different product behind a login.** If your submitted app is a note-taking tool and a specific user input switches on a video chat roulette, that is the textbook case.

- **Be careful with remote config that changes what the app is.** Toggling a banner or a button color is fine. Toggling in a generative image tool that was not present at review is not.

- **Keep your privacy labels and screenshots accurate.** Reviewers compare what you say you do with what the binary can do. A mismatch is a reason to look closer.

- **Audit your SDKs.** A third-party SDK can carry capabilities you did not know were there. If it can load remote code or enable a mode on its own schedule, you own that behavior.

Most legitimate teams use staged rollouts, A/B tests and feature flags every week. You do not need to stop. You need to make sure that the thing the reviewer sees is a faithful description of the thing your users will get, including features that arrive later.

## A Four-Hour Audit You Can Run This Week

You do not need a project plan for this. You need an afternoon and a list. Here is the audit I would run on any app in the groups above.

1. **List every place a user can put content in.** Photos, text, voice notes, avatars, bios, listings, comments. Write down the screen and the code path for each.

2. **List every place your app generates or alters an image or video.** Include features powered by a vendor API that your team forgot about.

3. **For each, write down what stops bad content on the way in and on the way out.** A blank cell is a gap. Fill the blanks with a moderation call before you worry about anything fancy.

4. **Find your report and block flows.** Tap through them on a real device. Confirm a report reaches a human, and time how long it takes to remove the content.

5. **List every remote flag and server-driven feature.** Mark any that change what the app can do for the user, as opposed to how it looks. Those need a mention in your review notes.

6. **Read your last three App Review notes and your current screenshots.** Check they still describe the app that is in the store.

Teams that have never done this usually find two or three gaps. The most common is an AI feature added in a sprint with no output filter. The second is a report button that emails an inbox nobody checks. Both are cheap to fix and expensive to explain after a removal.

## What the Safeguards Cost

Founders ask about cost first, so here is a realistic range for adding the basics to an existing app. These are market estimates in my own voice, and your numbers will move with your stack.

- **Input and output image moderation through a vendor API.** One to two weeks of engineering to wire up, plus per-image fees that are small at modest volume. At a hundred thousand images a month, the API bill is usually in the low hundreds of dollars, not thousands.

- **Report and block flows.** A week if you are starting from nothing, including the screens and a queue.

- **A basic admin and takedown tool.** One to two weeks. It can be an internal web page behind your login. It does not need to be pretty.

- **Human review of flagged content.** This is the real ongoing cost. A part-time moderator or a contracted service is the usual starting point, and it scales with your user count and your content risk.

In total, a small team can cover the basics in three to five weeks of engineering time, and the ongoing cost is mostly people. If that sounds like a lot, compare it with a removal. An app pulled from the store for a policy violation means weeks of lost installs, a reputation hit with your users, and an appeal process with no guaranteed outcome. For a bait-and-switch finding under 2.5.19, the risk extends to the developer account, which would take your other apps with it.

If you are still building and have not shipped, fold this into your plan now. It is far cheaper to put a moderation layer into the first version than to retrofit it. Our [mobile app launch checklist](/blog/mobile-app-launch-checklist-guide) is a good place to add these items to your own.

![Calculator and financial documents on a desk representing a project budget](https://images.unsplash.com/photo-1554224155-6726b3ff858f?w=800&q=80)

## If You Get a Rejection or a Warning

Say a notice arrives citing 1.2 or 2.5.19. The worst response is a fast, defensive reply. The best response is a fast, specific one.

Read the rejection text and find the exact guideline number. Reply in Resolution Center with what you changed, in plain sentences, and attach evidence where you can: a screenshot of the report flow, a description of the moderation step, a demo account that shows the feature. If the reviewer misread your app, say so politely and point to the screen that shows the truth.

If the message is a warning about content on your platform, remove the content and the account first, then reply. Apple's wording makes the failure to remedy violations after notice the trigger for escalation, so the clock matters. Keep a log of what you removed and when. If you have a second person on your team, make sure someone besides the founder can respond to App Review while you travel or sleep.

Our [App Store rejection guide](/blog/app-store-rejection-guide) walks through the appeal process in more detail, including when to escalate to the App Review Board. For the mechanics of a notice tied to AI features specifically, the structure is the same: acknowledge, show the fix, and ask for a re-review.

## What to Do Before You Ship Your Next Build

Apple's update is a signal about where review is heading. Expect more reviewers to ask how your AI features handle abuse, and to ask what the app does that they cannot see in a short test session. Teams that already have answers will pass without friction. Teams that do not will get questions in the middle of a launch.

Start with the audit above, and fix the gaps in order of risk: image generation without an output filter first, report flows second, undocumented server flags third. Write the answers down in your review notes template so every release carries them. Then read the guidelines page yourself, since this article is a summary and Apple's wording is the authority.

If you want a second set of eyes on an AI feature, a moderation layer or a submission that keeps bouncing, we do this work for founders regularly. [Book a free strategy call](/get-started) and bring your current feature list and your last App Review message.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/apple-app-review-guidelines-october-2026-ai-content-hidden-features)*