Migration to RC 4.0: subscription status ignored in Testflight

@Arnaud Hey friend!

Got a few questions for you to help us debug this 😊 

1. Did you set the `useStoreKit2IfAvailable` parameter to `true` when initializing `Purchases`? 
2. If so, does your App Store version already have that value set to `true` as well?
3. Are you using setting to specifying a user defaults when initializing or using the default user defaults?

Asking these questions because v4 does use StoreKit 1 by default. So this will help us determine if its an issue between v3 and v4 or StoreKit 1 and StoreKit 2

Thanks!

What’s weird is that installing I don’t get the same behavior on the 2 devices I’m using to try to understand what’s happening.
Device 1: personal AppleID (A) + sandbox AppleID (B)

Device 2: test AppleID (C) + sandbox AppleID (B)

Installing the Testflight app on Device 1 and purchasing triggers the purchase confirmation with my main account (A).

Doing the same thing on device 2 triggers the confirmation with the sandbox account (B)

Hey @joshdholtz, I feel better already with you around!

1. I did not set `useStoreKit2IfAvailable` and Device 2 is on iOS14 still.
2. the App Store version uses RC 3.x
3. Not sure if we’re talking about the same thing, but I’m calling `UserDefaults.standard.register(defaults: standardPreferences) with standardPreferences being a dictionnary loaded from a default plist (`Bundle.main.url(forResource: "DefaultPreferences", withExtension: ".plist")`)

[EDIT 1]

I smell something fishy in my code. It looks like that

struct MyApp: App {

  let purchasesManager = PurchaseManager.shared

    init() {

        UserDefaults.loadDefaults()

    }

}

But then, in the init of PurchaseManager.shared I have Purchases.configure(userDefaults: UserDefaults.shared).
So it must be calling loadDefautls() after Purchases uses the UserDefaults.

[EDIT 2]
That doesn’t seem to be it. Changing things to have Purchases.configure called after UserDefaults.loadDefaults() is called doesn’t fix it.

Okay, this is helping narrowing it down! One more question now... 😊 

1. In your code, are you doing any restores when going from App Store version to TestFlight version? Or is it expected for the purchases/unlocks to be there without a restore?

I think is all I need to keep looking into this and then testing it on my end!

@joshdholtz I don’t do any restore unless triggered by the user, I only use `getCustomerInfo`.

@joshdholtz I know what’s happening! ‍♂️

To support iOS extensions I changed configure in another commit from

Purchases.configure(withAPIKey: "key")

to 

Purchases.configure(withAPIKey: "key", appUserID: nil, observerMode: false, userDefaults: UserDefaults.shared)

This is what’s messing everything up.

I suppose I have to migrate the keys, but how?

@joshdholtz Correct! And I’m already handling a standard > shared migration, so I’ll just change what I do in there 🙂

Thanks a lot Josh, you’re a dev-saver!

@Arnaud No no, thank you for bringing this to our attention! It’s something we definitely need to handle better 😊 

Hit us up if there is anything else you need!

@joshdholtz That seems to do the trick

static func migrateRevenueCatToShared() {
        guard !shared.bool(forKey: UserDefaultsKeys.Shared.didMigrateRevenueCat) else { return }
        standard.dictionaryRepresentation().filter({ $0.key.hasPrefix("com.revenuecat") }).forEach { key, value in
            shared.set(value, forKey: key)
        }
        shared.set(true, forKey: UserDefaultsKeys.Shared.didMigrateRevenueCat)
}

PS: no Swift choice for code blocks here?!

@Arnaud Thanks for sending that over! This will be good to look at for if/when this happens again 😊 

And… sadly not 😔