Wondering how people are managing toggles in Mobile apps because of the following scenario. Let’s say you push build 1.0.0 to the App Store and release that build to the public. This build includes a Feature A (completed) and Feature B (partially complete). The team continues developing over the next two weeks and pushes build 1.1.0 to the App Store and releases it. This build includes code that completes Feature B (completed) and the beginnings of a new Feature C (partially complete). At this point in time there are some users of the app that have v1.1.0 and some that are using v1.0.0 still. How do you make sure that you don’t accidentally turn on Feature B until all the active clients are updated to version v1.1.0?

you can add the build version to the user attribute, and then target releases to versions. We currently don’t support SemVer comparisons, but you can do regexp matching

Ah thx so much

(or do some kind of semantic version to integer as the attribute)

hmm, yeah I guess conceptually what I want is for it in production to not be able to be enabled unless the user is on a “minimum version” or greater.

what SDK are you using?

Flutter

if you only have three levels in your semantic versioning - you could split it as attributes, eg: 1.2.12 would be: major_version: 1 minor_version: 2 build_version: 12 then the targeting could be very specific

yeah, I was just thinking that

correct

cool

yep

I am wondering where you all stand on contributions. We have effectively built a wrapper around the Flutter SDK to add support for it working in automated testing, for local overrides, etc. https://github.com/uptech/uptech-growthbook-sdk-flutter

oh cool

I also have a list of small things that I feel should change with the Flutter SDK to match the others better.

that would be great

Yeah, I can open issues and pull requests

we have a contribution guide

I am pretty experienced with Feature Toggles and built an open source library for them in the Ruby ecosystem years ago. https://github.com/uptech/togls