0

Am exploring options of adopting feature flag based development to deliver builds faster instead of getting tangled in release branch management rabbit hole.

As of now I am not able to find a good architecture pattern for iOS & Android native app development which will make it easier to adopt feature flags. We can use a simple condition based check, but that would mean we might get stuck if else conditions all over. Consider a screen in an eCommerce application. There might be multiple options to buy, config etc ... and instead of burying every feature behind a feature flag check is there a better pattern which can be adopted ?

6
  • 1
    "Mobile" is not a technology. You may have better luck asking for way to handle this with the technology and framework you use.
    – nvoigt
    Commented May 14, 2023 at 8:22
  • 1
    Clean? No. Testable? Try this. Commented May 14, 2023 at 8:56
  • mobile as in installed on peoples phones mobile, or mobile as in website on small screen?
    – Ewan
    Commented May 14, 2023 at 10:28
  • For iOS & Android applications. Sorry if I was not clear !
    – GoodSp33d
    Commented May 14, 2023 at 14:40
  • 1
    @GoodSp33d you were clear. But you failed to explain why that would matter to this problem. It's easy to assume it doesn't matter. Commented May 14, 2023 at 14:46

3 Answers 3

1

Native apps have a problem. That problem is that you can't tell people to roll back a version.

This means if you are introduction a new feature you need people to be able to upgrade to a new version, which can switch between the old and new feature set.

If the feature turns out to be buggy, then you can use the feature flag to remotely turn off the new feature on installed devices.

Essentially this means you have to use feature flags for every feature in your 'next version' and test with them both on and off.

Most of the articles you find on feature flags are about web applications, where you have the option of rolling back your website at any time, or having multiple versions of your site and routing traffic to either.

5
  • Yes understand that I cannot do a rollback. With apps you can only move forward and release again if its not fixable by flags either. But I was hoping to find some good architecture design to follow instead of relying on a lot of if/else commands.
    – GoodSp33d
    Commented May 17, 2023 at 18:04
  • you dont say how you are currently doing it, i assumed you were using something like launchdarkly.com
    – Ewan
    Commented May 17, 2023 at 18:06
  • We are not there yet. But we do have an in-house solution to store the flags and read em on the fly. But with most of the tools I end up with let showFeature = client.boolVariation(forKey: "flag-key-123abc", defaultValue: false) if showFeature { // Application code to show the feature else { // The code to run if the feature is off } Was hoping to see if we can avoid if/else chain. Because most likely if we adopt this we will run into multiple flags per screen.
    – GoodSp33d
    Commented May 17, 2023 at 18:13
  • I guess it depends on your app, but i would have duplicate pages and put the switch in the menu
    – Ewan
    Commented May 17, 2023 at 19:05
  • @GoodSp33d, much of computer science is about solving a problem through One More layer of indirection. Here, you may find it convenient for calling code to always unconditionally call showTheFeature();, and push all the conditional config nonsense down into some init routine which maps each showTheFeature symbol either to the implementing code or to some no-op code.
    – J_H
    Commented Oct 11, 2023 at 19:35
0

What I would do different: 1. Have a method with a proper name that relates to the feature. You don’t care about the key and default value. Like

if client.showFeature {
    … 
} else {
    …
}

Then one file that returns this and other settings. Now if the feature is hardcoded, comes from user set table settings or whatever doesn’t matter.

  1. And then you can use closures which can make your code more readable.
0

get stuck if else conditions all over

That's basically just how life will be. The key to keeping it manageable is:

  1. Be diligent about getting rid of stale FF code paths once a FF is on for everyone,
  2. Don't overuse them. If you are introducing a new feature, hide only e.g. the menu item for it behind the FF. That basically keeps the decision at a single place. If not a menubitem whatever UI paradigm is appropriate for your application.
  3. Otherwise, only sprinkle them in your code for dangerous/sketchy/questionable fixes where the need to potentially roll one back is actually present.
  4. Resist the temptation to use FFs as configuration workarounds just "for this one customer" just "this one time".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.