suggestion: Local overrides using launch flags

[lukeredpath]

Is your feature request related to a problem? Please describe.

It can be useful during early development to be able to enable/disable launch flags in local builds without interfering with others. One way could be to set up a specific environment in LaunchDarkly but this might not scale well to bigger teams. With a typical setup of a development and production environment, you may still want to produce local builds that have certain features enabled or disabled without changing things in LaunchDarkly.

Describe the solution you'd like

Because we wrap the LaunchDarkly SDK in a custom client interface in our app, we are able to very easily mock/stub flags in tests but also, we have the ability to enable or disable boolean flags using launch arguments in Xcode schemes.

Given a flag key of my-feature, we can add the launch flag enable-my-feature or disable-my-feature to enable or disable the flag accordingly - any launch flags set this way will override any values from LaunchDarkly regardless of whether targeting is enabled or not.

Describe alternatives you've considered An alternative would be to make use of multiple temporary environments in LaunchDarkly.

Additional context It might also be possible to support values besides boolean but for our needs a simple enable/disable toggle for boolean flags was enough for us.

One way we might typically use this is to temporarily add launch flags to our main development scheme in Xcode however if we are working on a bigger feature - usually across lots of small PRs - we will generally add a dedicated scheme for the new feature with the flag overrides enabled which we use during development and then delete once we are done.

[keelerm84]

My apologies for getting back to you so late. Thank you for this write-up!

I wanted to get your take on something. Some of our server-side SDKs support alternative flag source mechanisms; namely, test data sources and file-based sources.

While we do not currently have any plans to support this in the iOS SDK near term, I am curious if a solution like that might suit your needs.

[keelerm84]

Closing this due to lack of activity. We will keep this as a feature request in our internal tracker. Thank you!

[kylebrowning]

Id like to add that because LDClient is not mockable nor a protocol, we cannot use SwiftUI Previews when using LaunchDarkly. At least not a way that I have found. It really degrades our experience with LD.

Would be nice to see some SwiftUI Examples too where it wasn't one flag, or one view

[kylebrowning]

@keelerm84 would be nice to see where this is at in the timeline. As it stands I can't recommend LD until SwiftUI previews can work with a client in a manner that doesnt require me to inject the client into all of my view code.

[lukeredpath]

My recommendation would be to control the dependency and wrap the LaunchDarkly client in your own interface that you can easily stub out in previews (or tests). We use a lightweight struct-based wrapper for this and we have an entire API for stubbing particular keys (or overriding them with launch flags as suggested in my OP).

[kylebrowning]

I've tried this but my property wrapper requires a concrete type. Do you have any examples?

[kylebrowning]

Sorry I meant. My Environment to get the client requires a concrete type. Which my property wrapper looks at.