Best practice for feature flagging in mobile apps while avoiding incomplete functionality?

Question

I'm wondering how best to handle the scenario of releasing a mobile app that includes an incomplete feature behind a feature flag in one version and then the completed feature behind the flag in a subsequent version - and making sure users with a previous version don't encounter incomplete functionality.

Let's say I'm developing a feature called Weather for my iOS app. I release an incomplete version of the Weather feature to the App Store in release 1.1.0 - I put it behind a feature flag called show-weather and have that set to false on the backend. I then release version 2.0.0 of my app that has the completed Weather feature and flip show-weather to true on the backend. Uh oh! User's with 1.1.0 still installed are now seeing an incomplete version fo the Weather feature.

Ideas on mitigating this:

• The app sends its version number to the backend when retrieving feature flags and the backend sends false if the app version is too low
• The app implementation mocks the response from the feature flag service in version 1.1.0 to return false and replaces the mock with a real backend integration in version 2.0.0
• Users are forced to upgrade the app once a flagged feature is complete
• Developers don't merge incomplete features - feature flags are only used to toggle the appearance of full-realized features

The latter 2 options seem sub-optimal. We don't want to jar users frequently; and, we don't want developers to have to maintain long-running branches.

The first 2 might work but seem like something could easily be forgotten on the backend or frontend respectively.

What is an optimal solution for this scenario?

• Thomas Owens: Why is this a feature flag? Is there a reason why you can't push anything (non-breaking) to the server and update the client to take advantage of new server-side functionality? As long as the client is robust enough to handle any new data (which won't work for removals), I'm having trouble seeing the problem. However, I really wouldn't call this a "feature flag".

Answer 1

The old client version can’t handle weather data. Therefore it mustn’t even try, whatever the server says. So If you want most of the code present but not operational, your client itself must contain a feature flag, set at compile time.

The client displays weather data if the client feature flag allows it (changed at compile time) in a newer version, AND the server supports it.

Answer 2

Instead of a flag, the backend could return an app version that the client must have in order to use the feature. Example: "show-weather":">=2.0.0" could be used to indicate that clients starting with version 2.0.0 may use the feature.

Answer 3

The question is why you need an incomplete feature behind a run time feature flag.

As long as you are developing a larger feature which is not production-ready, you want to disable it completely in "production", and only enable it only in you local development environment. And that is a scenario where compile time feature flags are better suited for, combined with a build process which supports different developer and production release builds. This will easily allow you to enable the flag in your "dev environment" build, and disable it in the version released to the App Store.

Of course, you could also have an additional run-time feature flag for the same feature if you want to disable/enable the feature later in "version 2.0.0". But in "1.1.0", the functionality should be disabled in the released version by the compiler, so it cannot be activated in production accidentally.