Does an App Review approval mean an app has shipped? No. An approval tells you one submitted build passed review at one point in time. Shipping is owning everything that app does once it’s in users’ hands, including whatever changes after the reviewer moves on.
Having shipped FTNS.ai, KnowCap, Conquest, and 3D Trading Chart, I read every guideline change through one builder’s filter: what does the approval actually prove, and what stays with me after it?
What did Apple change in the App Review Guidelines on Oct. 16?
On Friday, Oct. 16, Apple published two Developer News posts: a rules post titled “Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps,” and a changelog titled “Updated App Review Guidelines are now available.” The guidelines page now reads “Last Updated: October 16, 2026.”
The item that matters for builders is guideline 2.5.19. It’s a new number for a long-standing policy formerly in 2.3.1, per Apple. The changelog says 2.5.19 “clarifies long-standing policy on hidden, dormant, or undocumented features, formerly covered in Guideline 2.3.1.” 9to5Mac made the same point: the rule “was already present in Section 2.3.1.” The underlying requirement didn’t start on Oct. 16.
Apple’s post describes the conduct in its own words, separate from the guideline text. It says the rule “clarifies our longstanding prohibition on apps misrepresenting what they do during the App Review process and then changing after approval — for example, adding features or functionality that weren’t included in the version of the app that was submitted to App Review.” The post’s penalty line: apps found doing this “are subject to removal from the App Store and removal from the Apple Developer Program.”
The update covers more ground. Under 1.2, Apple’s post says content moderation requirements “now explicitly cover nonconsensual intimate imagery — including imagery generated using AI tools.” Under Section 5, it says apps with content involving human trafficking or the exploitation of children “will be removed from the App Store and blocked from alternative distribution.” And Apple said in its Oct. 16 post: “Last year, we prevented over 150K apps with safety issues from reaching customers and terminated over 193K developer accounts for engaging in fraud and abuse.” Apple’s May 2026 fraud report said it removed nearly 59,000 bait-and-switch apps in 2025 and rejected over 22,000 submissions for hidden or undocumented features.
What does guideline 2.5.19 actually say, and what doesn’t it say?
Here is guideline 2.5.19 in full: “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. 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 details stand out. The duty runs to two audiences: functionality “should be clear to end users and App Review.” And the penalty is conditional. Hiding features is “grounds for removal,” a basis for action, not a promise of it. The guidelines page also tags 2.5.19 for Notarization Review as well as App Store Review, so it applies to alternative distribution too.
The disclosure duty sits next door, in 2.3.1(a): “All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.” The reviewer can only check what it’s told about and can reach.
Apple’s text doesn’t mention feature flags, remote config or A/B tests. Anything that changes what the app does has to be disclosed and reviewable under 2.3.1(a), and 2.5.2 bars downloading code that changes features; where a given configuration lands is Apple’s call. Guideline 2.5.2 says apps may not “download, install, or execute code which introduces or changes features or functionality of the app.” So I’m not saying any particular setup is off-limits, and I’m not saying it’s fine.
What does an App Review approval actually prove?
I’m not describing any App Review decision on my own apps here, and I’m not interpreting how Apple will enforce edge cases — this is the filter I use for what an approval actually proves.
An approval is a snapshot. A reviewer looked at one submitted build, with the notes and access the developer provided, at one moment. It doesn’t say the version in users’ hands next month is still the one that was reviewed, or who answers for the difference.
Apple’s post describes the failure case directly: apps that “misrepresent their purpose during review and only reveal harmful capabilities” after approval, which it calls “a tactic commonly known as bait-and-switch.” That’s the extreme version. The ordinary one is an app that drifts from what was reviewed because nobody owned keeping the two aligned.
Approval answers the reviewer’s question: does this build, as submitted, meet the guidelines? Shipping answers the user’s question: does this app keep doing what I was told it does? Only the builder can answer the second one.
Why do AI features make post-approval drift easier?
With AI features, behavior can move without a new binary — a prompt, a model, a server-side setting — so disclosure is the builder’s job, not the reviewer’s.
That’s framing, not a claim about how Apple treats model swaps; Apple’s text doesn’t address them.
The point is mechanism. With a conventional feature, a behavior change usually means a new build, and a new build goes through review. With an AI feature, the same binary can answer differently after a prompt edit, a model update or a server-side change. The approval doesn’t follow those changes. The builder has to.
My filter is simple: if a change alters what users get, I treat it as something to disclose, whatever mechanism moved it.
A builder’s checklist for keeping review and reality the same
This is a generic checklist, not compliance advice and not a story about any review of my apps.
- Describe new features and changes with specificity in Notes for Review, as 2.3.1(a) requires.
- Keep what the reviewer can reach the same as what users get.
- Treat a server or model switch that changes behavior like a release.
- Keep the “What’s New” text honest; 2.3.12 asks apps to clearly describe new features and product changes there.
None of that predicts what App Review will do with any given app. It just keeps the reviewed build and the shipped app describing the same thing.
How this fits “still isn’t shipping”
Apple opened iPhone Duo submissions. A recompile still isn’t shipping. made it for a recompile: a build that runs isn’t a product that’s ready. Muse hit #1. That isn’t the hard part of shipping an app. made it for a chart position. This one makes it for approval: a passed review is a snapshot of one build.
The ownership series runs the same test on AI tools. JetBrains Air unifies agents. It still doesn’t own the merge. covered code review. Google launched a universal Gemini agent. Finished work still isn’t ownership. covered finished work. A checkpoint passing isn’t someone owning what happens next.
Key takeaways
- Apple updated its App Review Guidelines on Friday, Oct. 16, 2026. The guidelines page reads “Last Updated: October 16, 2026.”
- Guideline 2.5.19 is a new number for a long-standing policy formerly in 2.3.1, per Apple. It says: “Don’t include any hidden, dormant, or undocumented features in your app.”
- The guideline makes hiding features “grounds for removal.” Apple’s post says apps that misrepresent themselves in review and then change are “subject to removal.” Neither is a promise.
- Apple’s text doesn’t mention feature flags, remote config or A/B tests. 2.3.1(a) requires changes to be described with specificity and accessible for review.
- An approval checks one build at one moment. Owning what the app does afterward stays with the builder.