When retrieving cached purchaser information after clearing NSUserDefaults, it causes a crash since appUserID is nil. about purchases-ios HOT 8 CLOSED

Basically if appUserID is nil, it causes a crash as a method appends the appUserID to a base key. If it's nil, that crashes... so I just check for the presence of an appUserId to prevent the crash.

from purchases-ios.

Hey! We'll look into this right away.

What do you mean by "clearing NSUserDefaults"?

The SDK should work with a blanked out NSUserDefaults.

from purchases-ios.

Hey thanks! Well we have a "Reset Settings" tool in our app that goes through NSUserDefaults and clears it out so I'm not really sure what caused that appUserId to become blank in the process. Maybe it stores that in NSUserDefaults, but the SDK state was still thinking it had one, I'm not sure exactly.

from purchases-ios.

Ok, so this crashed during the same session as when you cleared the defaults?

Restarting the app, everything worked ok yea? Just want to make sure we understand the severity of the issue.

We hadn't considered somebody deleting our cache keys from underneath us mid-session.

from purchases-ios.

Yes, once it was restarted it works fine. Understood, the "pulling the rug out from underneath you" part probably wasn't expected ;) But just adding a little check when appending the appUserId to make sure it isn't nil first would probably be easy defensive coding.

from purchases-ios.

@jkichline Sorry for the delay in responding. We're looking into moving out of NSUserDefaults and into another form of storage that's specific to the SDK so that we prevent this kind of collision in the future. We'll keep this issue open until we have a fix for this. Thanks for reporting!

from purchases-ios.

replied on #156, you should be able to pass in a different UserDefaults instance for RevenueCat to use and this issue shouldn't happen anymore.

from purchases-ios.

closing as a duplicate of #156

from purchases-ios.