We noticed that there's a pretty serious deadlock issue caused by the Statsig SDK when using UserDefaults in our app. Basically, Statsig is writing new values on a synchronous barrier queue and is trying to write those values to UserDefaults.standard. This issue was already brought up in #32 but that was closed (though I don't think it should have been).
An easy way to reproduce this is to have a subscriber to UserDefaults.didChangeNotification since UserDefaults own internal queue may not be flushed by the time Statsig calls into it.
The simplest fix here is that the Statsig SDK should create it's own UserDefaults suite instead of relying on UserDefaults.standard as storage. We are going to work around this issue by providing our own StorageProvider, but I wanted to bring it to your attention so you might fix this globally for everyone who is probably running into a similar deadlock.
We noticed that there's a pretty serious deadlock issue caused by the Statsig SDK when using UserDefaults in our app. Basically, Statsig is writing new values on a synchronous barrier queue and is trying to write those values to UserDefaults.standard. This issue was already brought up in #32 but that was closed (though I don't think it should have been).
An easy way to reproduce this is to have a subscriber to
UserDefaults.didChangeNotificationsince UserDefaults own internal queue may not be flushed by the time Statsig calls into it.The simplest fix here is that the Statsig SDK should create it's own UserDefaults suite instead of relying on UserDefaults.standard as storage. We are going to work around this issue by providing our own StorageProvider, but I wanted to bring it to your attention so you might fix this globally for everyone who is probably running into a similar deadlock.