Andy Garcia · freelance dev
FRENES
Back to the blog
Apple & Compliance

Apple Added Two App Review Rules on October 16. Rule 2.5.19 Can Cost You Your Developer Account

October 19, 2026 10 min read

On October 16, Apple published a new version of its App Review Guidelines, replacing the one dated June 8. The changelog has seven entries. Two are new rules: 2.3.14, on creative assets, and 2.5.19, on hidden features. The others clarify which apps fall under 1.2 on user-generated content, rewrite the link-out bullet in 3.1.1(a), add removal from the App Store and a block from alternative distribution to section 5, and add documentation links before and after submission.

Apple framed the update in a companion post about nonconsensual intimate imagery and bait-and-switch apps: apps that pass review as one thing and become another after approval. The same post says that last year (2025), Apple prevented more than 150,000 apps with safety issues from reaching customers and terminated more than 193,000 developer accounts for fraud and abuse. TechCrunch, on October 19, read the update as a ban on nudify apps that masquerade as regular apps to get through review.

That is the target. But I ship iOS apps as an indie developer, and the same sentences apply to a solo developer with a feature flag as to a fraud operation. So I read the June 8 and October 16 versions side by side. Here is what changed, rule by rule.

2.5.19: an old ban, a new address, a new sentence

The ban itself is not new. Until October 16, guideline 2.3.1(a) opened with: "Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review." That sentence is gone from 2.3.1(a). It now opens 2.5.19, word for word, followed by a new one: "Attempting to hide undocumented features in your app binary, such as through code obfuscation or other methods, is grounds for removal of your app from the App Store and termination of your developer account."

Two things moved. The rule left section 2.3, Accurate Metadata, for section 2.5, Software Requirements: a hidden feature is now filed under the binary, not under the store listing. And the rule carries its own penalty sentence, with obfuscation named as an example.

Read that sentence closely. It does not ban obfuscation, which has legitimate uses, anti-tamper among them. It bans using obfuscation, or anything else, to hide undocumented features. The word doing the work is "undocumented".

The penalty itself is not new. In the June text, the next sentence of 2.3.1(a) made misleading marketing "similarly" grounds for removal and termination of the developer account, and 2.3.1(b), which stays, says egregious or repeated behavior is grounds for removal from the Apple Developer Program. In July, Apple told 9to5Mac it had already terminated the developer accounts behind 25 apps of the kind described below. What changed is that the termination sentence now sits on hidden features directly, in the binary, with obfuscation named.

Apple's companion post describes the conduct it means: adding features or functionality that were not included in the version of the app submitted to App Review. Neither the guideline nor the post mentions feature flags, remote config or A/B tests. My reading is that the risk sits in one pattern: a path in the binary that review never sees, switched on from a server afterwards. 9to5Mac reported in July on more than 60 apps built that way: they behaved as their screenshots showed virtually everywhere except Brazil, and revealed betting platforms when opened from a Brazilian IP address. The build instructions 9to5Mac found called for remotely controlled routing to the local app, an in-app web page or an external website.

Honest apps gate features by region, cohort or date too. The line 2.5.19 draws is whether App Review knew. What remains of 2.3.1(a) still says that all new features, functionality and product changes must be described "with specificity" in the Notes for Review, that generic descriptions will be rejected, and that they must be accessible for review.

2.3.14: creative assets cannot quote a price

Creative assets are images and videos that, according to Apple's asset guidance, appear across the App Store in iOS 27 and iPadOS 27 and later: the product page header, search results, and placements when your app is featured. The new rule says they must pertain to your app's content and functionality or overarching brand, and should not include inappropriate content, references to other apps with an intent to mislead, unverifiable product claims, or "specific or discounted pricing information".

Apple's best practices page adds its own list: no website URLs, no copyright symbols, no references to other platforms, no Apple recognitions such as Editor's Choice or App of the Day. Assets must meet a 4+ age rating even if the app is rated higher, and games that include violence may use action imagery but must avoid gore and weapons pointed directly at a person or the audience.

The same page suggests creative assets for seasonal offerings. So the rule in practice: promote the season, not the price. A "50% off" header is exactly what 2.3.14 rules out. It extends a line already in 2.3.7, which keeps prices out of app names, subtitles, screenshots and previews. I also build a strategy game, Doomsday: M.A.D., and the line about violent imagery is the one I would put at the top of any brief for store artwork.

1.2: AI creation apps are now named

The June version of 1.2 began: "Apps with user-generated content present particular challenges". The October version begins: "Apps that enable users to create, generate, upload, share, or otherwise contribute content", lists nonconsensual intimate imagery among the challenges, and names three kinds of apps: social media, user-generated content platforms and AI content creation apps. Such apps must include a filter for objectionable material, a way to report offensive content with timely responses, a way to block abusive users, and published contact information.

Then a new sentence: developers who fail to implement appropriate safeguards, or fail to remediate identified violations after notice, "may be considered in violation of the Developer Code of Conduct". Follow that to 5.6: "Your Developer Program account will be terminated if you engage in activities or actions that are not in accordance with the Developer Code of Conduct." Apple's post says the moderation requirements now explicitly cover nonconsensual intimate imagery, including imagery generated with AI tools, as content apps must proactively prevent and remove.

Earlier this year I wrote about building an AI wallpaper app. Under the October 16 wording, an app like that is an AI content creation app in 1.2's own terms. The text does not say how "block abusive users" applies when nobody else sees what you generate. I would not wait for a reviewer to answer that: a moderation step on the prompt and on the output, a report button on every generated image, and a contact address that someone actually reads.

3.1.1(a), section 5, and the edits the changelog skipped

3.1.1(a) used to let entitled developers link to "a website the developer owns or maintains responsibility for". It now says "a permitted destination", and the StoreKit bullet adds: "Approved destinations may vary by region." The Music Streaming Services Entitlement is folded into that bullet, and the entitlements are limited to specific storefronts "and only on certain platforms in each of those storefronts". The United States storefront still needs no entitlement for buttons and external links. I would not read "permitted destination" as "any URL": check what your entitlement allows in your region. The reader-app entitlement in 3.1.3(a) still says "a web site the developer owns or maintains responsibility for".

Section 5 used to stop at notifying the authorities about apps found to facilitate human trafficking or the exploitation of children. It now adds that such apps will be removed from the App Store and blocked from alternative distribution.

The changelog also skips an editorial pass: every "e.g." in the June text, 35 of them, is gone, replaced by "such as" or "for example", and so is the one "i.e.". That last edit touches money. 3.1.3(f), the exemption for free stand-alone companions to a paid web tool, used to say "(i.e. VoIP, Cloud Storage, Email Services, Web Hosting)". It now reads "a paid web-based tool for VoIP, Cloud Storage, Email Services, or Web Hosting". Strictly, "i.e." already meant "that is", but a parenthesis like that is easy to read as examples. The new sentence leaves no room: four categories. If you build a free companion app for a client's SaaS outside those four, that exemption is not your route.

What I would check before the next submission

I orchestrate my work with Claude Code, and this is the kind of audit I would hand it first, then verify by hand.

  1. List every remote flag, kill switch, experiment and region gate the binary reads. For each, note whether its feature is visible in the build under review. Anything that ships dark and turns on later goes in the Notes for Review, with how to reach it.
  2. Make sure debug and internal menus are compiled out of release builds, not hidden behind a gesture.
  3. If you obfuscate, be ready to say why, and make sure nothing behind it is undocumented.
  4. If you push JavaScript updates over the air in a React Native app, hold each update against the companion post's description: features that were not in the version submitted to review.
  5. Brief whoever makes your store art: no prices, no discounts, no URLs, no awards you cannot prove, imagery fit for 4+.
  6. If users can generate anything, ship the filter, the report button, blocking and a contact address before the reviewer asks.

Apple says translations will follow within one month. Until then, read the English page.

None of this slows down an honest release. "The reviewer did not see it" was never a safe shortcut; since October 16, the rule says in writing that it is a liability on the account, and the cheapest place to fix that is the review notes, before you press Submit.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk