Crash on logout call to Firebase auth with proceeding Purchases.shared.reset

[heumn]

Calling Auth.auth().signOut() crashes with the following stack trace if you have added an observer to

Auth.auth().addStateDidChangeListener

and call Purchases.shared.reset as per your guide

2019-12-25 12:52:16.687635+0100 Charged Production[95849:23984344] [Common] _BSMachError: port 12b03; (os/kern) invalid capability (0x14) "Unable to insert COPY_SEND"
2019-12-25 12:52:16.779726+0100 Charged Production[95849:23984344] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSCFConstantString stringByAppendingString:]: nil argument'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff23c7127e __exceptionPreprocess + 350
	1   libobjc.A.dylib                     0x00007fff513fbb20 objc_exception_throw + 48
	2   Foundation                          0x00007fff2577900e -[NSString stringByAppendingFormat:] + 0
	3   Purchases                           0x00000001065ac746 -[RCPurchases attributionDataUserDefaultCacheKeyForAppUserID:] + 70
	4   Purchases                           0x00000001065a505e -[RCPurchases resetWithCompletionBlock:] + 142
	5   Charged Production                  0x0000000102b27133 $s18Charged_Production23ApplicationConfiguratorC9configureyySo13UIApplicationCFZySo7FIRAuthC_So7FIRUserCSgtcfU_ + 499
	6   Charged Production                  0x0000000102b27a4f $sSo7FIRAuthCSo7FIRUserCSgIeggg_AbEIeyByy_TR + 95
	7   Charged Production                  0x0000000102e99b74 __41-[FIRAuth addAuthStateDidChangeListener:]_block_invoke + 532
	8   Charged Production                  0x0000000102e9a133 __39-[FIRAuth addIDTokenDidChangeListener:]_block_invoke + 163
	9   Foundation                          0x00007fff2574b44e -[__NSObserver _doit:] + 287
	10  CoreFoundation                      0x00007fff23b9b5bc __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12

I have enough bugs that I produce myself, so would be awesome to not have to deal with yours as well ;)

[vegaro]

Are you by any chance clearing NSUserDefaults when signing out the user?

[heumn]

Yes!

[vegaro]

We hadn't considered somebody deleting our cache keys from underneath us mid-session. Doing so will leave the SDK in a state that can only be fixed by calling configure again since we rely on different data we write to NSUserDefaults on initialization.

Can you, instead of clearing the whole NSUserDefaults, remove the specific keys you are using?

[heumn]

Thanks!

Of course, I could, but isn't it a bit dangerous as a third party SDK to rely upon NSUserDefaults:

• always be available (it is not, see here as an example)
• not change from overwrites of the client app

🤔

Not trying to be difficult, I will of course remedy this crash by doing as you propose. Just want to have a discussion so I can learn about your reasoning as a third party SDK developer 😃.

[aboedo]

@heumn Sorry for the delay in the response. You're right, relying on NSUserDefaults is a bit dangerous. 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!

[aboedo]

@heumn update on this: The SDK allows for you to specify a separate instance of NSUserDefaults to be used, using a different domain.
By specifying a different instance, you can safely delete your app's standard UserDefaults without running into this issue.
Note that if you want to delete the info stored on the RevenueCat SDK, you have to call resetWithCompletionBlock.

Here's an example of sending in a different user defaults instance for the RevenueCat SDK:

guard let revenueCatUserDefaults = UserDefaults.init(suiteName: "com.myapp.revenuecat") else {
    fatalError("can't create user defaults for RevenueCat domain")
}
Purchases.configure(withAPIKey: "your api key here",
                    appUserID: nil,
                    observerMode: false,
                    userDefaults: revenueCatUserDefaults)
        

Important: Make sure that the domain that you use to instantiate the NSUserDefaults passed into RevenueCat is different from the domain of the main bundle of your app.

[heumn]

This makes much more sense :) Thanks for the update and thanks for an awesome service

[aboedo]

one last note here: if you change the domain on an existing app, the first time it runs, the SDK won't find the existing data, so it'll be the equivalent of calling resetWithCompletion. Make sure to pass in the appUserID if your user is logged in. After that it will work normally.

[aboedo]

closing for now, feel free to reopen if you run into any more issues with this