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.

Hello, I have an app that receives critical alarms. This is usually done through remote push notifications from the server, but to add redundancy I'd like to add a MQTT connection as well. There are scenarios where internet connection might be missing (but there is a local WiFi connection to the server) hence I'd like to deliver the alarms directly from server to client without going out via the Internet. The problem is that according to all restrictions on iOS, the MQTT connection will not be maintained in the background and disconnect occurs within 20-30 sec after going in the background and shutting the screen. I'm aware of all the background modes that iOS allows but none fall within this scenario. Is there a way to maintain a MQTT connection (or some other type of network connection) in the background on iOS?