Is there a difference between token lifetime on sandbox vs production?
I am locked into using a sandbox environment at the moment and am wondering what is causing my token to expire/reset.
I am not uninstalling the app nor updating the iOS version between apparent token expirations.
I do force close and background the app as part of dev/testing.
I am also using a VoIP certificate which I believe is valid for both production and sandbox.
The app being run on the iOS devices is built and pushed direct from Xcode.
What appears to be happening is the token gets changed sometime between when the app is no longer running on the receiving device and when it should be receiving the push notification. The app doesn't have a chance to run to update the token before then.
It's not completely documented as to what invalidates an APNS token, the docs do mention:
If the user restores backup data to a new device or computer, or reinstalls the operating system, the device token changes.
However, I imagine these aren't the only scenarios that cause a token to expire. What is documented is the fact that you should not cache the token but instead always pull it from the system if & when required.
See Registering for Remote Notifications, specifically:
Moreover, never cache a device token and give that to your provider; always get the token from the system whenever you need it. If your app has previously registered, calling registerForRemoteNotifications results in the operating system passing the device token to the delegate immediately without incurring additional overhead. Also note that the delegate method may be called any time the device token changes, not just in response to your app registering or re-registering.
Related
Just out of curiosity, do sandbox push notifications for iOS expire? The reason I am asking is, yesterday my push notifications were working perfectly for my device and since then I haven't changed the code. Today I wanted to push another notification to further test and all of a sudden, no notification was received. I had to reinstall the app and get another token for it to work.
So, do sandbox tokens expire, or do I possibly have a more serious issue at hand when I go to live?
As of now nowhere it is documented regarding the token expiry. But as an experience and from an architectural point, device tokens will not expire for a smaller duration of time. Because it will create a lot of effort for APNS to generate a new token every time if that is the case. Anyway, you can check your server logs to see the acknowledgement you receive from APNS if it is a failure to deliver a notification.
The device token probably changed from the prior version of the app you were testing. You should check the token each time you launch the app and ensure it's registered because it's likely to periodically change.
https://developer.apple.com/documentation/usernotifications/registering_your_app_with_apns
Never cache device tokens in local storage. APNs issues a new token when the user restores a device from a backup, when the user installs your app on a new device, and when the user reinstalls the operating system. If you ask the system to provide the token each time, you’re guaranteed to get an up-to-date token.
I am developing an iOS app in which i have implemented Push Notification.
Everything is working fine.
But just wish to ask if device Token for my Apple device will ever change??
Also do we need internet connectivity for generating device token.
Thanks
device Token for my Apple device will ever change
-- YES. If you restores backup data to a new device or reinstall the operating system, the device token changes. So my suggestion is to update the server with token
do we need internet connectivity for generating device token
-- as far as I know, YES. When you register user, you call method for registration for push notification. This on successful registration call the delegate method -
- (void)application:(UIApplication *)app didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken
indicating you are registered successfully for a push notification or on failure it calls -
- (void)application:(UIApplication*)application didFailToRegisterForRemoteNotificationsWithError:(NSError*)error
indicating failed to register for notification.
You can check it by turning off network and running your application.
Based on the Apple Documentation, the answer is YES:
The form of this phase of token trust ensures that only APNs generates
the token which it will later honor, and it can assure itself that a
token handed to it by a device is the same token that it previously
provisioned for that particular device—and only for that device.
If the user restores backup data to a new device or reinstalls the
operating system, the device token changes.
From the apple docs -
The device token is your key to sending push notifications to your app on a specific device. Device tokens can change, so your app needs to reregister every time it is launched and pass the received token back to your server. If you fail to update the device token, remote notifications might not make their way to the user’s device.
Device tokens always change when the user restores backup data to a new device or computer or reinstalls the operating system. When migrating data to a new device or computer, the user must launch your app once before remote notifications can be delivered to that device.
Never cache a device token; always get the token from the system whenever you need it. If your app previously registered for remote notifications, calling the registerForRemoteNotifications method again does not incur any additional overhead, and iOS returns the existing device token to your app delegate immediately. In addition, iOS calls your delegate method any time the device token changes, not just in response to your app registering or re-registering.
For more APNS Doc
I was recently troubleshooting an issue with push notifications for a user. I was a bit confused by the guidance here, indicating that the token would only change in rare circumstances, such as "moving to a new device" or "re-installing the OS".
While the above events are likely valid events where the token is updated, I also see the token is updated simply when the user updates the OS on their device.
For example:
When my device runs iOS 15.4.1, and I install an application and request a push notification token, I'm provided with token "A".
After I update my device to iOS 15.7, with the same application still installed, and request a push notification token, I'm provided with token "B".
Therefore while rare events like restoring backup data to a new device or re-installing the OS are valid for this case, more frequent events such as a user simply updating the OS of their device are also valid for causing the push notification token to change.
Thus, this will likely change quite frequently and should always be requested from the device and updated on your server.
Most documentation advises to register for remote notifications on launch, and on receipt of the token, push this to a server with any other app-specific settings (e.g. user, in-app Push settings). However, I am not sure how to handle the following corner case.
If the user launches the app without connectivity, no token will be received. Moments later, connectivity is restored. The user attempts to change some setting in the app, which should prompt a post to my server including the setting and the token. However, the token is still nil.
Would it not be better, instead, to register for notifications every time before attempting to post the setting? It seems unnecessary to request this token on launch since it might not be needed, and even worse, might be nil when it is needed.
I think it's still best to register for push notifications when the app is launched. When you get the device token, you don't have to immediately send it to your server. You can store it locally on the device. When your logic requires to send the device token (as well as other settings) to your server, get the locally saved token. If the saved token is null, try registering again, and send the token to your server once you get it.
Note that when the app is launched you should register for push notifications even if you a have a previous locally stored device token (due to the remote chance that Apple would decide to change the device token).
Apple recommends you should call register every time the app comes to the foreground ( either when you open it or when it comes back from background).
This call does not serve only as a way to get the push notification token but also to let Apple know that this application is still interested in receiving push notification. If you call this method only once, or rarely and you don't send push notifications that often, you could run into a scenario where the token you have been using, that is stored on the server is no longer a valid token (after enough time has passed without a token being acknowledged by a device apple will no longer consider the token valid. )
I was testing my iOS app I found one interesting thing that even my phone is in airplane mode and I have also switched off WIFI, my app is able to receive the the Device Token after registering for push notification.
I have also tried even after removing app and its associated certificate from the iPhone.
but got same results.
How is it possible, any idea ?
thanks in advance.
This is from the APNS programming guide :
By requesting the device token and passing it to the provider every
time your application launches, you help to ensure that the provider
has the current token for the device. If a user restores a backup to a
device or computer other than the one that the backup was created for
(for example, the user migrates data to a new device or computer), he
or she must launch the application at least once for it to receive
notifications again. If the user restores backup data to a new device
or computer, or reinstalls the operating system, the device token
changes. Moreover, never cache a device token and give that to your
provider; always get the token from the system whenever you need it.
If your application has previously registered, calling registerForRemoteNotificationTypes: results in the operating system
passing the device token to the delegate immediately without incurring
additional overhead.
It implies that if your application is already registered for push notifications, calling the registerForRemoteNotificationTypes doesn't access the APNS server.
The fact that you uninstalled the app doesn't unregister it from APNS. You can prove that to yourself by calling the feedback service immediately after uninstalling the app. You wouldn't get the device token from the feedback service in this case, because the APN service doesn't know you uninstalled the app. Only if you send notifications to the device after uninstalling the app, the APN service will know the app was uninstalled.
It seems to be customary for apps that are using APN to get the token from the OS whenever the app launches. However if an app has already obtained it once, is there any point in it bothering to obtain it again (and consequently sending it to the server if its already done so).
Can the APN token obtained from the OS ever change?
The answer to your question is inside Apple docs (Local and Push Notification Programming Guide):
By requesting the device token and passing it to the provider every time your application launches, you help to ensure that the provider has the current token for the device. If a user restores a backup to a device or computer other than the one that the backup was created for (for example, the user migrates data to a new device or computer), he or she must launch the application at least once for it to receive notifications again. If the user restores backup data to a new device or computer, or reinstalls the operating system, the device token changes. Moreover, never cache a device token and give that to your provider; always get the token from the system whenever you need it. If your application has previously registered, calling registerForRemoteNotificationTypes: results in the operating system passing the device token to the delegate immediately without incurring additional overhead.