New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MBL-721] Remote Config Local Feature Flags #1817
Conversation
β¦lsViewController
β¦environment instance
Generated by π« Danger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, nice quick work here.
For some reason I'm not getting the flags to show in-app:
Simulator.Screen.Recording.-.iPhone.8.-.2023-05-09.at.15.04.29.mp4
Also address the questions below and I'll take another look, likely on Thursday. I want to focus heads down and get the xcode upgrade ready for review tomorrow.
Kickstarter-iOS/Features/BetaTools/Controller/BetaToolsViewController.swift
Outdated
Show resolved
Hide resolved
...mizelyFeatureFlagToolsViewControllerTests/testOptimizelyFeatureFlagToolsViewController.1.png
Outdated
Show resolved
Hide resolved
Library/ViewModels/RemoteConfigFeatureFlagToolsViewModelTests.swift
Outdated
Show resolved
Hide resolved
addressed your comments @msadoon take your time reviewing. no rush! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep so good to go - I noticed that the defaults load first not the dashboard values (on fresh install). Then re-launching picks up the dashboard values. Just as a discussion this seems acceptable to me, but let me know if you think dashboard values should be shown on first install launch instead of default values.
π² What
Now that we have RemoteConfig configured, lets get our local feature flags in our debug menu working.
π€ Why
Some background context on why the change is needed.
π How
These toggles will first reference values stored in user defaults, if there is one, before referencing the values currently published in our firebase console.
Allowing us to test our app with different flags enbaled/disabled without impacting production.
We're using the same pattern here that we've had with Optimizely, so this is mostly renames and making sure that we're referencing the
RemoteConfigClientType
that is now inAppEnvironment
π See
Trello, screenshots, external resources?
β Acceptance criteria
Make sure you run the app using our
AppCenter Alpha
scheme to test.