I am asking about two situations:
1) After we do a regular update from the App Store
2) After we simulate an update, by downloading a current version from a Store and installing & running a new version from within Xcode,
does push notification token changes? If changes, how often eg. each time, or from time to time?
I ask this, because I was doing some testing, where I want to preserve Documents folder after an update. So this can be easily done like I described above, by downloading the app from the Store, and running a new version from within Xcode. But, I noticed that push notifications stopped to work. Then I repeated this few times (uninstall the app, install it from the store, then run the upgraded version from Xcode) and every time push notifications worked.
I wonder if this was due to push notification token change?
See Apple Docs:
Never cache device tokens; always get them from the system when you
need them. Although device tokens are unique to an app and device,
they can change over time. The device token can change at any time but
is guaranteed to be different when the user restores their device from
a backup, when the user installs your app on a new device, and when
the user reinstalls the operating system. Fetching the token from the
system ensures that you always have the current token needed to
communicate with APNs. In addition, if the token has not changed,
fetching it is fast and does not incur any significant overhead.
So based on Apple docs there are at least 3 places that it changes:
Restore from backup
installs on new device
reinstalling the OS
So a typical update doesn't change them. I don't ever remembering myself having to agree to receive after an update...
IMPORTANT NOTE:
If a user logs out of the app and a new user logs into the same device, then the token would remain the same. Why? Because there's no class or messaging system exposed to developers to let the OS know it has to deregister a token from device.
Hence you must unregister that token from that user/account ie you have to make some sort of network call you to your platform, otherwise new user would be receiving push notifications that belong to previous user.
As far as I know,
1) Regular update from the App Store - APNS token doesn't change.
2) It's a bit tricky. And I believe token changes. First I want to let you know the appstore version uses APNS production certificate and the build run from with xcode uses development one. It will generate different token. And if you still send push notification to the apple push production server, you won't get them on your xcode version. You need to send them to the apple push sandbox server.
Related
So I'm running into a peculiar problem that I have not been able to find much information on. Looking for any input or experience at all.
I have recorded the deviceToken of an existing app install using Urban Airship. Then deleting the app and reinstalling, I recorded the new device token as well. These tokens are different. From the UA test panel, I am able to send a test push to both of these tokens and the device receives 2 pushes, one for each token, even though the first token has since been uninstalled. But, in UA device lookup, both tokens are marked as active.
This was only caught after getting our push server running which triggers a push once every morning at most, based on a hosted file that determines the push contents and if one should happen. My development device is now getting up to 8 pushes at once from the server.
There are ways to unsubscribe or unregister for push notifications with Apple, UA, and the server, but I'm wondering on the best practices for this. There is no way to get the uninstall event either which would be the only time to unsubscribe. Is the best solution just to wait for UA to determine a token is inactive? I have found this list here for reasons a token could be inactive: http://docs.urbanairship.com/reference/troubleshooting/ios-push.html#inactive-device-token
But none seem to apply here, especially because some of these device tokens are nearly a month old and still sending to my test device. The app uses an Enterprise profile so this is happening in a production environment.
Are you getting the same channel every time? Usually reinstalls will generate the same channel which is tied to a single device token. Then when apple generates a new token it will update the channel's token. You are probably better off contacting support directly. They will be able to help gather all the device info they need and look up registration and push records to figure out whats going on.
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.
I have a game running in Appstore which connects to one of our development server and now as it is live, I am not able to send push notifications. I need to move it from develpoment server to production server (Urban airship) and it gives me new Api/secret keys. If I update these keys and update my application, will it show alert popup/register to all existing device again to new server? We have around 75k users and I can't afford to loose them! Any idea whats the safest way to play!!
Got it!
The way iOS works, you don't have to worry about the Devices Tokens not registering. Devices will have two Device Tokens per install of an app, a Production Device Token and a Development Device Token, so you should see the new Production Device Token get registered to the app as soon as the user updates and opens the app the next time around. And then you'll be set!
We added receiving push notifications to an iPhone app. Everything was working in the test/sandbox environment, we were getting token id's from the app and could send push notifications from our server.
But now the app is approved and came out of the Appstore we were getting empty push tokens/notifications id's send to our server. We already have over 600 of them... Note that end users do get the popup to approve of receiving notifications in the app, the app is just sending empty tokens to our server after approval. So probably empty tokens are handed out by the APNS server.
The following issue showed us that this is probably due to missing 'push notification' entitlement in the provisioning profile we used to make the build for the app store:
How do I check if an iOS distribution provisioning profile has push notifications enabled?
The missing entitlement was due to a bug in Apple's provisiong protal website, but after 'Modify any existing profile before you download the new one' as mentioned in the following article
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ProvisioningDevelopment/ProvisioningDevelopment.html
We now have the correct entitlement in our .mobileprovision file:
<key>Entitlements</key>
<dict>
..
<key>aps-environment</key>
<string>production</string>
..
So we are rebuilding our app and adding it to the store. And hoping to get push notifications then.
I hope the above might help some others. But now to get to my actual question: Will we start receiving new push tokens also for the 600+ users that already downloaded the current version when they install the next update out of the store? Or do we need to add some initial code to our app? The registerForRemoteNotifications method is right now only called on application startup. Will it also be triggered when the push token id is changed from empty ('') to an actual token? Of course we do not want to wait another (small) week for the new AppStore approval and only then find out that push notification still aren't working for some users. I'm hoping some expert out there can tell us.
Note: We are using an iPhone app developed in MonoTouch, and using the (old) APNS-Sharp library to send the notifications from our server, but I don't think those details are relevant for this issue.
When those 600+ users install the next update and run the application again, your application will call registerForRemoteNotifications (since you said you call it on startup), and will get the non empty device token (when application:didRegisterForRemoteNotificationsWithDeviceToken: is called).
Apple state in their docs that you should always call this method at startup instead of using a cached copy of the device token, because the device token is not guaranteed to remain the same. So you shouldn't have any problem.
Here's the relevant quote from the APNS docs :
An application should register every time it launches and give its
provider the current token. It calls
the registerForRemoteNotificationTypes: method to kick off the
registration process. The parameter of this method takes a
UIRemoteNotificationType (or, for OS X, a NSRemoteNotificationType)
bit mask that specifies the initial types of notifications that the
application wishes to receive—for example, icon-badging and sounds,
but not alert messages. In iOS, users can thereafter modify the
enabled notification types in the Notifications preference of the
Settings application. In both iOS and OS X, you can retrieve the
currently enabled notification types by calling the
enabledRemoteNotificationTypes method. The operating system does not
badge icons, display alert messages, or play alert sounds if any of
these notifications types are not enabled, even if they are specified
in the notification payload.
This is also relevant :
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 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.