Feature Flags: option to fully control when the feature flags are reloaded

[theop-luma]

Problem Statement

Currently, PostHogConfig has a preloadFeatureFlags property which if you switch to false, doesn't load the feature flags during initial setup. This doesn't seem to stop however the feature flags being reloaded later when the user is first identified in identify or the session is reset. In those cases reloadFeatureFlags is called since shouldReloadFlagsForTesting seems to always be true.

Solution Brainstorm

It would be really good if we could fully control when these flags are reloaded, to make sure we schedule it at a convenient time for the app.

[marandaneto]

Hello @theop-luma

shouldReloadFlagsForTesting is only used for testing, so we can isolate unit/integration tests.

preloadFeatureFlags is indeed for pre-loading feature flags, once the app starts (and only), and you can control the reloading if disabled.

reset and identify must reload flags because the user actually has changed otherwise you'd be using maybe somebody else's flags.

Previously we were not doing this but we noticed that every user was combining a call to identify or reset always with reloadFeatureFlags so we just went ahead and removed the boilerplate from their end, the other issue was people complaining about wrong flags about calling reset or identify and not calling reloadFeatureFlags.

What is the use case that you need control over reloading flags after identify or reset?

Thanks.

[theop-luma]

I see... the reason we'd prefer having full control is:

1. When the app is first launching or user is first logging in, it's best if you can explicitly control every network request that's going out and their order/priority so you can make sure the most vital information is coming in first.
2. It's more convenient to be able to wrap the reloadFeatureFlags call into a checked continuation so you know immediately when it's done instead of waiting on a NotificationCenter which is a little clunky. In general more use of async/await and actors, reducing the use of all the NSLocks I think would be a very good change.

Not really urgent requests, but more about quality of life I'd say.

[marandaneto]

1. that is already possible with preloadFeatureFlags.
2. the problem is back compatibility, to support older iOS versions (<= 14) we cannot rely on everything async/await (Swift <= 5.4) yet as soon as we deprecate versions that don't support that, we'd refactor the SDK to be fully async/await/actors, etc.

That said, I understand the use case now but we'd need to drop support for iOS 13 and 14 first.

[marandaneto]

Another option is to have a callback called when flags are reloaded, you can set this callback during SDK init, instead of the notification center, would that help?
Example https://posthog.com/docs/libraries/android#ensuring-flags-are-loaded-before-usage (onFeatureFlags)