Using RemoteConfig with Swift Concurrency

[vrutberg]

Hi,

I'm wondering what the recommended way is to use Firebase Remote Config with Swift Concurrency.

Specifically:

• Is it safe to call methods like fetchAndActivate() from a non-MainActor context, or should these APIs always be used on the main actor?

• Is it safe to read Remote Config values from a non-MainActor context, or are there any thread-safety considerations?

At the moment I'm importing FirebaseRemoteConfig using @preconcurrency to silence concurrency warnings/errors, but I'm not sure if that reflects the intended usage or if I should instead isolate access (e.g. behind @MainActor or an actor).

Any guidance on the expected concurrency model for Remote Config would be greatly appreciated.

Best,
Viktor

[peterfriese]

Hi @vrutberg,

1. Is it safe to call fetchAndActivate() from a non-MainActor context?

Yes. The fetchAndActivate() method in the Firebase SDK is designed as an asynchronous operation.

2. Is it safe to read Remote Config values from a non-MainActor context?

Yes, with caveats. RemoteConfigValue instances are thread-safe snapshots of data. However, the RemoteConfig instance itself represents a shared state that can be mutated (e.g., when a fetch finishes and is activated).

While the SDK handles internal synchronization to prevent crashes, reading values across different threads might lead to consistency issues if one thread activates new values while another is still processing old ones.

3. Should I use @preconcurrency or isolate access?

Transition to isolation is recommended.

• @preconcurrency: This is a valid measure that silences warnings while the we're working towards full Sendable conformance.
• Recommended Isolation Pattern:
  • @mainactor: Ideal if your configuration values directly drive UI elements (e.g., toggling feature visibility). This ensures that any reactive updates (using @Observable or @Published) happen on the main thread.
  • Actor: If the configuration is used purely for background logic or data processing, isolating it within a custom actor provides a safe way to manage the shared RemoteConfig state across multiple background tasks.

Hope this helps!

Cheers,
Peter

[vrutberg]

Thanks @peterfriese, this is very helpful.

I'll keep the @preconcurrency annotation for now and look into isolating RemoteConfig usage behind an actor.