Apple push notifications - getting empty push token from production app - will push tokens be sent after fix provisioning profile issue

Question

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.

Answer 1

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.