Hello,
Scenario:
- My app is running in the foreground, logged into my backend server and I have registered for push notifications and received a push token. I have pin code activated on the phone.
- I make some code changes and re-flash it in Xcode, the app is running in debug mode wired to Xcode.
- I put the app in the background and lock the screen and wait 30 sec until data protection is activated and the keychain cannot be accessed.
- I send a push notification. In this case didRegisterForRemoteNotificationsWithDeviceToken if often called with the same push token as I had before.
Data is protected in this state, hence I cannot access the auth token and send the token to the server. In this case it is not needed since the token is the same, but it got me a bit worried. In didRegisterForRemoteNotificationsWithDeviceToken I send the push token to the server, as the Apple docs recommend.
My concern now is: could didRegisterForRemoteNotificationsWithDeviceToken be called in a real scenario when the phone is locked and data protection is activated?
The Apple docs say:
Device tokens can change periodically, so caching the value risks sending an invalid token to your server.
And gives an example:
For example, UIKit calls the method when the user launches an app after having restored a device from data that is not the device’s backup data.
In this case, since the user is initiating it, the phone is unlocked so data should be unprotected. But that is one example, what more scenarios could there be that triggers this function, and could data be protected in those scenarios?
I'm worried that it could be triggered, even if its rare, in a state where data protection is activated, hence I cannot send the new push token to the server, and thus future remote notifications from the server will not be received by my app until the users logs out and logs in again.