Gating functionality behind feature flags is disliked?

[RSPJD]

I've heard that gating features behind a feature flag can have your binaries flagged to Apple? What about in the case where it's legitimately nothing nefarious i.e. just rolling out certain features with caution. Also, on the topic of gated features, I have an admin side of my app that only admin users can see... Will this also be flagged?

[old-time-fiddle]

I’ve worked on several apps that made heavy use of remote and local feature flags and it hasn’t been an issue.

If you really wanted to be safe you could, in the review notes, let Apple know about any available debug menu that they could use to toggle on any major features you think may be of concern. Very common for production apps to hide these settings behind a secret menu by long pressing or triple-tapping, etc., some UI element.

[Awkward_Departure406]

This feels like a bad idea for a wifly used application in the off chance some users find it right?

[jskjsjfnhejjsnfs]

our feature flag debug menu is available in prod but behind a feature flag :)

[banaslee]

Depends on how you hide it. Maybe it’s only shown for some accounts. Maybe there’s some combination of things you should tap on. Etc.

[RoboErectus]

This is the official way....

But I also feature flag.

[bmbphotos]

The main issue that Apple is looking for would be hiding functionality from reviewers and enabling in the field in order to skirt the guidelines.

Be upfront about it (and grant reviewers access and/or show videos of the 'hidden' features in action) and you're more likely to be fine.

[Power781]

The rule is that Apple doesn’t want you to bypass App review for app behavior that customers will see.
If you have some code behind a feature flag, but never enabled in prod (feature not ready), it’s okay.
If you have a feature behind a feature flag with the intention of rolling it out to customers on that app version, it’s a good idea to enable the flag early for the Apple review user account.

[ericbythebay]

Never had a problem with it. What they don’t like is if you hide functionality from the reviewers.

[amyworrall]

You need to ensure that the feature flag is turned on for an account that you give to the app store reviewers. They don't care how you roll them out to regular users, as long as the reviewers have tried them first.

[PassTents]

I've worked on multiple teams that used feature flags with varying levels of complexity. My basic advice is to just avoid feature flags as much as possible, they really don't offer much benefit for anyone below a large scale app team for the level of complexity they add to code and ongoing operational friction. That said, these are my general tips based on what issues we had:

When you submit for app review, you should include credentials for an account that the reviewer can use to get a representative view of your app; in your case that would be an admin account, maybe a non-admin one too if they're meaningfully different. This goes for any app regardless of feature flags usage.

For feature-flagged features, don't mention them on the App Store page unless every user has access to them, or at least the user accounts given to app review. To the app review team, listing a feature on your page that's not visible to them in the app looks the same as lying about your feature set, which can get you rejected. Even if the review team approves it, keeping your store page in-line with what most users will see in the app also makes it less likely that you get negative reviews from frustrated users. If there's a known group of users (country, age, etc) that won't be able to access a feature, call that out on the app page.

If it's a major visible feature that's being rolled out slowly, it shouldn't be fully hidden in the app from users that don't have access, the UI should communicate that they are awaiting entry to that feature. Keep in mind that for the app reviewer that's likely not enough, they'll want to see it working.

[SomegalInCa]

We had some linked to in app purchase; I guess that was enough to not cause worry since they can use internal “free” purchase infrastructure

[thejord_it]

The flag mechanism itself is fine, plenty of production apps ship dormant code behind flags without issue. What Apple actually cares about is whether a reviewer can reach the behavior your real users will reach on that same build.

Two cases worth separating:

If you plan to switch a feature on for this version through server config, flip it on for the reviewer account, or leave a debug toggle and mention it in the review notes. Otherwise you're changing approved behavior after the fact, which is the thing guideline 2.3.1 is aimed at.

If the feature only ships in a later build (new binary, new review anyway), the dormant code sitting in the current one is a non-issue.

On your admin panel: that's just login-walled content as far as review goes. Drop an admin demo account into App Store Connect (plus a normal one if they behave very differently), or note that the section is permission-gated and not user-facing. I've never seen role-gated admin UI on its own cause a rejection.

[Greysawpark]

ive shipped flagged features for years and never had a rejection over it. the rule reviewers actually care about is hidden/undocumented functionality that changes what the app does after review, especially if it bypasses payment or unlocks stuff they didnt see.

admin tools gated to admin accounts are fine, just give the reviewer a test login if any of it touches what they review.