Different Feature Flag Caching Mechanisms

[brianmichel]

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

We use a fork of this SDK to power feature flagging on our macOS application. While we understand this is explicitly named the ios-client-sdk it serves as a defacto macOS SDK since it drops in without any issue (perhaps an issue we should discuss). Due to flags getting cached in user defaults anyone on macOS can simply use the defaults command to read and write data to these values which can easily break an application. This is a fine solution for iOS since there's no access to the device where you could run said command, but isn't sufficient for macOS implementations (or perhaps in any other environment capable of running Swift code).

Describe the solution you'd like
We'd like the ability to specify the caching storage mechanism, and even provide our own to meet the needs of different scenarios/environments. You can see a quick and dirty proof of concept that I built on our fork (apologies for being a little out of date) v5...thebrowsercompany:ios-client-sdk:brian/caching-options about how the system could work. You could imagine other implementations that serialize this information to a file somewhere else, or an encrypted database of some sort. You get the idea.

Describe alternatives you've considered
I'm open to other ideas, however I don't know what other alternative solutions here there might be since there isn't any option today of providing alternative implementations to the caching mechanism .

Additional context
N/A

[louis-launchdarkly]

Hello @brianmichel, thank you for reaching out about this use case. While we cannot promise a timeline, this seems like a useful enhancement to have. I put this into the backlog and will discuss it with the team.

Filed as 222822.

[brianmichel]

Hello @brianmichel, thank you for reaching out about this use case. While we cannot promise a timeline, this seems like a useful enhancement to have. I put this into the backlog and will discuss it with the team.

Filed as 222822.

Thanks for the quick reply @louis-launchdarkly! Do you think an approach similar to what I've linked to would be sufficient? I think I can make it a bit more dynamic so someone could easily pass in a custom instance as some sort of associated value on an enumeration.

I'd be happy to try to contribute that back if you think the design is sufficient.

[brianmichel]

Hey @louis-launchdarkly just wanted to see if there was any update here before the end of the year

[nalexn]

Hey @louis-launchdarkly ,

Can you bump the priority for this feature request? We've been debugging an issue where LD would not remember the last used flag values and narrowed it down to UserDefaults not always storing the flags when the payload is large enough.
We use ~1kb json flag in LD and this is causing UserDefaults to sometimes discard the cache. This is causing flickering in our app as features are being enabled / disabled at random after the app launch.
UserDefaults are also accessible by the user on iOS and can be manipulated externally, which is a big risk for some apps.