Urgent ⚠️ SDK is crashing our app on startup

[EliotAndres]

Expected Behavior

Our app starts without crashing

Current Behavior

App crashes

Possible Solution

Fix your remote config

Steps to Reproduce

Use Photoroom app

Environment

• SDK Version: 1.13.2 Amplitude Swift 1.0.12 Amplitude Code
• Device: iPhone 16 Pro
• OS Version: iOS 18
  I opened case 357633

Stack traces:

`AmplitudeCore`(1) await resume partial function for partial apply forwarder for closure #1 @Sendable () async throws -> AmplitudeCore.RemoteConfigClient.RemoteConfigInfo in AmplitudeCore.RemoteConfigClient._updateConfigs() -> Swift.Task<AmplitudeCore.RemoteConfigClient.RemoteConfigInfo, Swift.Error>:`

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Attempt to insert non-property list object {
    analyticsSDK =     {
    };
    sessionReplay =     {
        "sr_ios_privacy_config" =         {
            blockSelector =             (
            );
            defaultMaskLevel = light;
            maskSelector =             (
            );
            unmaskSelector =             (
            );
        };
        "sr_ios_sampling_config" =         {
            "capture_enabled" = 1;
            "disabled_reason" = "<null>";
            "sample_rate" = "0.0014000000000000002";
        };
    };
} for key config'

[EliotAndres]

cc @crleona

[eschos24]

We are also getting this crash.

[zeusmedina]

Impacting all of our users

[travischapman]

We are also seeing this crash

[matejkepes]

We've also noticed ~1 hr ago

[EliotAndres]

What we know so far:

• Call to https://sr-client-cfg.amplitude.com/config?api_key=OUR_API_KEY_&config_keys=sessionReplay.sr_ios_privacy_config&config_keys=sessionReplay.sr_ios_sampling_config&config_keys=analyticsSDK.browserSDK seems to crash. If you block this call, it no longer crashes
• Changing session replay config doesn't help
• Switching to invalid API key no longer crashes

[EliotAndres]

It started at 5:30 UTC time today

[crleona]

We are taking a look and reverting a service change that may be the culprit.

[zeusmedina]

I don't know the specifics of the underlying implementation but this seems like something the SDK should be able to handle gracefully going forward.

[EliotAndres]

It's fixed for us. We'd appreciate a post-mortem as well as implementation tips to ensure this doesn't happen again 🙏

[aurelhubert]

It seems to come from the addition of "disabled_reason": null in the sr_ios_sampling_config object

[crleona]

The backend change is reverted and apps functionality should be returning to normal.

[travischapman]

It seems to come from the addition of "disabled_reason": null in the sr_ios_sampling_config object

Yes, null values are unsupported in plists and that is the underlying crash exception we saw as well.

For the Amplitude team, might I kindly suggest using a strongly typed Swift struct for the response object and encoding the config to Data when storing in UserDefaults.

Storing the cached response as a [String: Sendable] ultimately led to an outage for our app impacting the reputation of our applications. The intention of my message is not meant to come across negatively. We would appreciate additional automated testing of the impacted area to ensure it doesn't become an issue again.