Apple's rule 2.5.19: show App Review everything your app can do

What Apple published on Friday

On Friday, October 16, Apple updated its App Review Guidelines and added a new rule, 2.5.19. In plain terms: don't put hidden, dormant, or undocumented features in your app. What the app does should be clear to the people using it and to App Review. And if you try to hide undocumented features in the binary, through code obfuscation or any other way, Apple says that's grounds for pulling the app and terminating your developer account.

By the weekend, iOS developers on X were asking the obvious question. Most apps of any size ship with feature flags, remote config, staged rollouts, or A/B tests. Does this rule make all of that a problem?

We build and ship mobile apps, so we read the rule, Apple's two announcements, and the guideline it came out of. Our short answer: it isn't a new ban on feature flags. It's a sharper statement of a rule that already existed, and it comes down to one question. Can the reviewer see and understand everything this build can do?

What changed, and what didn't

Start with what Apple itself says. Its change log for the update describes 2.5.19 as a new guideline that "clarifies long-standing policy on hidden, dormant, or undocumented features, formerly covered in Guideline 2.3.1." So the rule isn't new. It has moved to its own number and become more explicit.

Apple's companion post explains why. The rule targets apps that misrepresent what they do during review and then change after approval, for example by adding features that weren't in the version Apple reviewed. The example Apple gives is bait-and-switch "nudification" apps, which look harmless in review and reveal what they really do once they're live. 9to5Mac, covering the change on Friday, noted that the prohibition was already in 2.3.1. It also pointed back to its own July investigation, which found gambling apps that only showed betting to people with Brazilian IP addresses.

What's actually new is in the wording. The rule now names code obfuscation as a hiding method, and it spells out the consequences: removal from the App Store and termination of the developer account.

What didn't change matters just as much. Guideline 2.3.1(a) still says new features, functionality, and product changes must be described with specificity in the Notes for Review field in App Store Connect, and must be accessible for review. Apple still rejects generic descriptions. The same update also touched 1.2 (nonconsensual intimate imagery, including AI-generated images), added 2.3.14 on creative assets, changed the link entitlement wording in 3.1.1(a), and tightened Section 5 on trafficking and child exploitation. None of those are about flags either.

So is this about feature flags?

Not in anything Apple has published. Neither the guideline nor either announcement mentions feature flags, A/B testing, remote config, or staged rollouts. Anyone telling you Apple has banned them, or blessed them, is going further than the sources do.

Here's how we read it, and this is our studio's advice, not Apple's stated position. The rule is about the gap between the app the reviewer saw and the app your users get. A flag isn't a problem on its own. A flag that opens up something the reviewer never saw is.

That gives you a rough order of risk. A flag that gates a feature you've described and the reviewer can reach is the safe end, as long as the notes say how to turn it on. A staged rollout of a feature that's in this build is fine in our reading, as long as it's described in Notes for Review and switched on for the demo account. A/B variants of a disclosed feature, like two layouts of the same checkout, look lower risk to us, because nothing new appears that the reviewer didn't see. That's a judgment call, though, not something Apple has said.

At the other end, dormant code for a feature you haven't announced, waiting for a server switch after approval, is close to what the rule describes. So are debug menus, test toggles, and mock modes left in a release build. They may be harmless, but they're undocumented functionality sitting in the binary, and they're cheap to remove.

Where ordinary teams get caught

The apps Apple is chasing are deliberately hiding something. Most teams that get caught out by a rule like this aren't. They just never tidied up. Here's what we'd look for.

The leftover developer menu. A hidden gesture or a long press on the version number that opens environment switchers, fake purchases, or a "skip login" button. It was handy during testing, nobody took it out, and now it's undocumented functionality in your release build.

Next month's feature, merged early. It's common to merge unfinished work behind a flag that stays off, then flip it on from the server when it's ready. If that flip happens without a new submission and without a word in the review notes, you've shipped a feature App Review never saw. Merging early isn't the problem. Switching it on without telling anyone is.

Remote config that can do too much. Changing a banner, a color, or copy from the server is one thing. A config key that can unlock a whole new section of the app is another. If a key can change what the app does rather than how it looks, treat it like a feature and describe it.

Obfuscation you can't explain. Some teams use code protection tools for good reasons. The rule names obfuscation as a way of hiding features, so make sure yours isn't covering functionality the reviewer can't reach, and make sure someone on the team can say what it protects.

Old flags nobody owns. Flags that outlive their purpose turn into dormant code paths. Our note on killing a flag properly covers how to retire one instead of leaving it half alive.

A release-build checklist

This is the list we'd run before every App Store submission now. It takes an hour the first time and a few minutes after that.

1. List every flag and remote config key the release build reads. Use the code, not memory. For each one, note what it changes and whether it's on or off at launch.
2. Strip debug, test, and mock toggles from the release configuration. Compile them out rather than hiding them behind a gesture.
3. Check for unannounced features. If code for something you haven't disclosed is in the build, either take it out or describe it and make it reachable. Don't plan to switch it on later without a new submission.
4. Write the flags into Notes for Review. For anything gated, say what it is, where it lives, and how the reviewer can see it. Be specific, because 2.3.1(a) says generic notes get rejected.
5. Turn the flags on for the demo account. The reviewer should be able to reach every feature you described, using the account you gave them.
6. Record who can flip each flag in production, and agree that turning on a feature that wasn't reviewed means a new submission.
7. Keep a dated copy of the notes and the flag states. If a reviewer asks later what was in the build, you can answer in one message.

None of this is extra paperwork for its own sake. It's the same thing Apple asks for in 2.3.1(a), written down so it happens every time.

Put this into practice

Three questions for whoever owns your iOS releases this week:

• If a reviewer opened our current build, is there anything it can do that they wouldn't find?
• Is there code in the App Store build for a feature we haven't announced?
• Do our last three sets of review notes name the flagged features, or just say "bug fixes and improvements"?

If the honest answer to any of them is "not sure," that's the work. It's usually a few hours of cleanup, not a rewrite. For the rest of the review routine, like demo accounts, notes, and the account rules that trip teams up, our note on getting through App Review on the first try covers the basics.

We design and build mobile apps, including release pipelines that keep test toggles out of production builds and a flag list that matches the review notes. If a 2.5.19 rejection landed on your desk, or you're not sure what your build is carrying, send us what you're seeing.

Related work: WorkStep.