Rejected Device Tokens

A device token is created when an app sends a request for remote notifications to Apple Push Notification Service (APNS). This registers the device, cryptographically generates the device token, and returns it to the device. 

Apple will reject a device token that is not recognized in the particular push environment.

Apple will also reject a device token if the bundle ID in the build and in the uploaded certificate do not match. This can occur when the production APNS generates a device token (e.g. because it's an ad hoc build), but the app is pointing to a development App Key. The opposite is also possible. Device tokens generated by development builds are only valid in the sandbox. If that App Key is in production mode, APNS will reject the device token.

Airship does not validate device tokens. Apple validates device tokens when a push is attempted. We have to wait for the results from Apple so we accept any 64 character combination as a device token and pass it on to Apple. Any errors that occur when a push is attempted are logged in the Airship error console for 24 hours.

Dashboard Example for rejected device tokens:

You can see if you have rejected device tokens in the Error Console at the bottom of the Airship Dashboard. 

Airship_-_Overview_for_Goat.png

 

Steps to double check to ensure proper configuration:

  1. Make sure the build has the same bundle ID as the push certificate you uploaded on the Airship dashboard.


    TakeHomeTest_xcodeproj.pngAirship_-_API_keys_for_com_urbanairship_richpush.png

    Certificates__Identifiers___Profiles_-_Apple_Developer.png

  2. Do NOT include a production App Key in your application unless it is a distribution build. (e.g., ad hoc or App Store)

    AirshipConfig_plist___Edited.png

  3. Ensure ad hoc builds are using production App Keys in your airshipConfig.plist file and inProduction is set to YES/true/1 in your airshipConfig.plist file.

    AirshipConfig_plist___Edited1.png

  4. For projects migrated from Xcode versions prior to 8.x - Ensure there is an APS Environment entitlement:



  5. Provisioning profiles can be sticky. They may need to be deleted from the test device and re-generated with just the one needed. This will ensure that the correct profile is used.
  6. Always use a development provisioning profile for a development App Key.
  7. Always use an ad hoc provisioning profile for a production App Key.
  8. Verify that the same device tokens are not appearing in both development and production apps. This shouldn't happen, and indicates a production/development mismatch.
  9. Use the codesign tool to verify the build's entitlement. Look for aps-environment: codesign -dvvvv --entitlements - <YourAppName>.app

Related Content:

Was this article helpful?
0 out of 0 found this helpful
Submit a request