Remote Notifications

By supporting remote notifications you can provide up-to-date information to users of your app, even when the app is not running. To be able to receive and handle remote notifications, your app must:

  1. Enable remote notifications.

  2. Register with Apple Push Notification service (APNs) and receive an app-specific device token.

  3. Send the device token to your notification provider server.

  4. Implement support for handling incoming remote notifications.

This chapter explains these steps, all of which you implement in your app. For more about providers, which are servers that you deploy and manage for building and sending notification requests to APNs—read APNs Overview.

Note: The ability of APNs to deliver remote notifications to a nonrunning app requires the app to have been launched at least once On an iOS device if a user force-quits your app using the app multitasking UI, the app does not receive remote notifications until the user relaunches it.

Note: If you need help with your application configuration inside iTunes Connect and Xcode, please, point your browser to a Setup and test push notifications guide.

Enabling the Push Notifications Capability

For an app to handle remote notifications, it must have the proper entitlements to talk to APNs. You add this entitlement to your app using the Capabilities pane of your Xcode project.

Apps without required entitlements are rejected during the App Store review process. During testing, trying to register with APNs without the proper entitlement returns an error.

With IOS Native plugin all you need to do is enable the ANS API under the User Notification settings

Development Environment

Normally you want to leave the value "Enabled". Since you can't use a production certificate in debug/development. When you do and 'Archive' Xcode automatically set it to production and you can see this when you try to submit your app to iTunes connect for TestFlight/Review or for adHoc deployment.

Registering to Receive Remote Notifications

Each time your app launches, it must register with APNs. The methods to use differ according to the platform, but in all cases it works as follows:

  1. Your app asks to be registered with APNs.
  2. On successful registration, APNs sends an app-specific device token to the device.
  3. The system delivers the device to your app by calling a method in your app delegate.
  4. Your app sends the device token to the app’s associated provider.

See the code snippets showing these steps:

using SA.iOS.UIKit;
ISN_UIApplication.ApplicationDelegate.DidRegisterForRemoteNotifications.AddListener((result) => {
    if(result.IsSucceeded) {
        var token = result.DeviceTokenUTF8;
        Debug.Log("ANS token string:" + token);
    } else {
        Debug.Log("Error: " + result.Error.Message);

An app-specific device token is globally unique and identifies one app-device combination. Upon receiving a device token from APNs in your app, it is your responsibility to open a network connection to your provider. It is also your responsibility, in your app, to forward then the device token along with any other relevant data you want to send to the provider. When the provider later sends remote notification requests to APNs, it must include the device token, along with the notification payload. For more on this, see APNs Overview.

Never cache device tokens in your app; instead, get them from the system when you need them. APNs issues a new device token to your app when certain events happen. The device token is guaranteed to be different, for example, when a 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. Fetching the token, rather than relying on a cache, ensures that you have the current device token needed for your provider to communicate with APNs. When you attempt to fetch a device token but it has not changed, the fetch method returns quickly.

Note: When a device token has changed, the user must launch your app once before APNs can once again deliver remote notifications to the device.