Ok, so I read and think I understand how the Restore Settings work, but have some further clarification settings.
We’re in the process of migrating to a new backend where all users will need to sign up again with a new system where they will get user IDs. These user IDs are the ones that will not be recycled changed. We don’t want a scenario where users can log out of their new accounts, create a new one, restore subscriptions (mint a new subscriber), then give those credentials to someone else or what have you. That’s why we want to have the Block Restores enabled, but we aren’t sure how to handle the migration process from the old version of our app to the new one.
What I was thinking - first, we don’t enable this Block Restores Setting and let everyone migrate to the new login system, restore purchases if they need. Our old version is also using the old SDK and we aren’t calling reset user ID anywhere - what will happen when we upgrade to the new SDK and haven’t called login yet? Will their old user ID count as “logged in” and by calling logIn method again (after they go through the new signup), will they just be aliased to the new userID.
Any advice on how to handle this situation would be appreciated :)
@Zachary Shakked ,
I think you have the right idea here. You can hold off on using Block restores and wait till everyone is migrated over. If you need to switch from one provided App User Id to another, it's okay to call the
.logIn()method directly - you do not need to call
Does that answer your question?
That does help @jazmine - one additional question - turning on Block Restores will only apply moving forward correct? Any previously restored purchases for users will be good to go?