Feature flags are not camouflage: ship honestly through App Review

A feature flag may control behaviour, but it must not deceive

Apple updated its App Review Guidelines on 16 October 2026. The new Guideline 2.5.19 draws a boundary that product teams already needed to respect but can no longer overlook: apps must not contain hidden, dormant or undocumented functionality. Apple explicitly includes functionality concealed through code obfuscation and names removal from the App Store and termination of the Developer Program account as possible consequences.

That may sound alarming to teams using feature flags, remote configuration or staged rollouts. Those tools are not the problem. A flag that controls an already reviewed path, limits initial exposure or enables a safe rollback is different from functionality deliberately hidden during review and switched on afterwards.

The decisive question is not Does this app have a switch? It is Can the review team understand what the feature is, how to reach it and what may change after approval?

Where a legitimate rollout becomes bait-and-switch

A sound feature-flag process separates deployment from release without changing the identity of the product. The reviewed binary contains an understandable feature; the flag initially limits reach or operational risk.

The boundary is crossed when a team:

• shows App Review a deliberately reduced or materially different app;
• makes a significant feature appear through remote config only after approval;
• omits a code path from App Review Notes;
• serves reviewers different responses or content from real users;
• uses obfuscation or downloaded behaviour to conceal the purpose of the app;
• leaves permanently disabled functionality in the build with no owner, test or removal date.

Apple's Guideline 2.3.1(a) reinforces the point: new features and product changes must be described specifically in App Review Notes and be accessible for review. Generic descriptions can be rejected. Guideline 2.5.2 also says apps may not download, install or execute code that introduces or changes features or functionality.

A kill switch for a faulty, already reviewed path is therefore not the same thing as a mechanism that loads a new product into an approved binary.

Give every flag a small identity card

Feature flags are often treated as temporary implementation details. In practice they affect product behaviour, support, privacy and review. We keep a short record for every release-relevant flag:

• Name and owner: Who decides activation and removal?
• Purpose: Which risk or hypothesis does the flag control?
• Default state: What does a fresh installation see with no special configuration?
• Audience: Internal testers, a TestFlight group, region, percentage rollout or everyone?
• Review path: Which navigation, role and data make the feature visible?
• Dependencies: Does the path require a backend switch, account, entitlement or in-app purchase?
• Data and permissions: Does it change data use, tracking, camera, location or notifications?
• Expiry: When will the flag be removed or converted into permanent configuration?

This need not become another management system. A versioned YAML file or a section in the release ticket is enough, provided that the build, configuration and App Review Notes refer to the same state.

Write App Review Notes as a test procedure

Reviewers should not have to discover a feature by accident. Useful Notes are a short, reproducible procedure rather than marketing copy.

For every new or materially changed feature, include:

1. What is new? One sentence describing the user value and actual behaviour.
2. Where does the path start? Exact navigation from launch.
3. What access is required? Demo account, role, region or prepared sample data.
4. Which configuration applies? The relevant flag and expected state, without exposing internal secrets.
5. Which dependency must be available? Backend, Bluetooth device, subscription or another prerequisite.
6. How can the result be verified? The expected screen or action.
7. What is intentionally not public yet? A clearly bounded TestFlight, pilot or staged rollout.

Apple's Guideline 2.1 requires complete, reviewable submissions. Backend services must be live during review, and apps with account-based features need an active demo account or, with prior approval, a fully featured demo mode. A polished explanation does not help if the actual path ends at an expired login.

Remote config must not become reviewer detection

Remote configuration is valuable because teams can adjust thresholds, ordering or exposure without producing a new binary for every operational change. It becomes dangerous when it deliberately gives App Review a different experience from real users.

A robust setup follows four rules:

• Configuration is selected by app version and genuine product cohort, not a suspected reviewer IP address or test device.
• The configuration revision expected at submission is recorded and can be reconstructed later.
• The review account sees the same feature path intended for the documented audience.
• If remote config is unavailable, the app enters a safe, documented default state — not a second, secret app.

A revision ID is usually sufficient in logs. Tokens, personal data and complete internal configuration do not belong there. The team needs to know which switch state accompanied a reviewed build without creating a new security problem.

Test four states before every submission

A single happy path rarely exposes flag problems. Before uploading, we test the same release candidate in four states.

Fresh installation: no cached values, default configuration and a new account. This reveals accidental reliance on an old flag value.

Review access: the exact credentials and steps from the Notes. Someone who did not build the feature follows the instructions word for word.

Enabled cohort: the feature is fully active. We check navigation, permissions, privacy copy, purchases, analytics and failure states.

Rollback or offline: the flag is turned off or remote config is unavailable. Data must remain intact and the app must return to an understandable state.

Screenshots of these four paths are not a replacement for testing, but they are useful evidence in the release ticket. Better still is a small automated matrix that exercises critical navigation in default, active and fallback states.

TestFlight is the right harbour for unfinished experiments

Guideline 2.2 is clear: demos, betas and trial versions do not belong in the App Store; TestFlight is the intended route. An unfinished experiment should not travel inside a public build as a hidden production technique.

A clean sequence looks like this:

1. An internal group verifies technical stability and data migration.
2. An external TestFlight group validates comprehension and real use.
3. The team decides whether the feature, metadata, privacy declarations and support are ready.
4. The feature is fully documented in App Review Notes and submitted.
5. After approval, an observed percentage rollout begins with a prepared rollback path.

A staged rollout reduces operational risk. It does not replace review for significant new functionality. The flag may change exposure, not swap out the purpose of the reviewed build.

Dormant code needs an expiry date

Feature flags age quickly. After a few releases, teams often no longer know whether a disabled path is still needed, which data it expects or whether it even compiles. Guideline 2.5.19 now makes that technical residue an additional review risk.

When creating a temporary flag, we also create:

• a decision date;
• a responsible owner;
• a ticket to remove the old path;
• a metric or explicit condition for keeping, changing or deleting it.

Once the new variant is stable, the flag and old code disappear. When an experiment loses, the experimental path disappears as well. “Maybe later” is not a lifecycle.

A short preflight checklist

Before submission, we want nine yeses:

• Is every feature in the build known and assigned to an owner?
• Do the App Review Notes describe every new or changed feature specifically?
• Can someone outside the feature team reproduce the review path?
• Do the demo account and backend work without internal assistance?
• Does App Review avoid an artificially different product state?
• Are the remote-config revision and safe defaults documented?
• Have default, enabled and rollback states been tested?
• Are unfinished experiments in TestFlight rather than the public store?
• Do temporary flags have an expiry and a removal ticket?

Feature flags remain a good engineering tool. They make releases smaller, rollouts more controlled and recovery faster. But they must not create a second layer where a product secretly changes identity after review. The best response to Apple's clarification is not better camouflage. It is better release discipline: visible functionality, reproducible Notes, tested configuration and code that disappears when its switch is no longer needed.

Sources

• Apple Developer News: Updated App Review Guidelines
• Apple App Review Guidelines: 2.1, 2.2, 2.3.1, 2.5.2 and 2.5.19
• Apple TestFlight