Getting Started

This is a developers’ guide for setting up an Airship configuration for native iOS apps. We will take you through the basic technical steps for configuring Apple and UA services, show you how to send your first basic push notification and Message Center message, and provide detailed samples and instructions for using advanced Airship features.


An Important Note about Location

As of Spring 2019, Apple has begun rejecting applications that use, or appear to use, Core Location services without supplying usage descriptions in their Info.plist files. In Airship SDK 11.0, all references to CoreLocation were removed from the core library and placed in a separate location framework. Developers with no need for location services can continue to use Airship as before, but for those who have been using the UALocation class, see the Location sections for updated setup instructions.


As of SDK 10.2 and Apple’s current App Store review policies, apps bulding against Airship without location usage descriptions in Info.plist are likely to be rejected. To avoid this, either use SDK 11.0 or newer, or add usage description strings to your Info.plist file under the NSLocationAlwaysUsageDescription, NSLocationWhenInUseUsageDescription, and NSLocationAlwaysAndWhenInUseUsageDescription keys.

Apple Setup

Before you can integrate Airship into your iOS apps, there are a handful of steps you must take on the Apple end of things, which requires membership in the iOS Developer Program.

We will be using the Apple Push Notification Service (APNs) as the transport method for iOS push notifications. In the next section we will configure a development and production app for push services.

Production vs. Development Apps

When you create or edit an Airship project (and thus its application record on our server), you must select whether your app system is Test (development for sending test messages), or Live (production for sending messages to customers). Apple treats the two servers separately, so a device token for test/sandbox will not work on live/production. Because of this, we suggest making two projects in the Airship dashboard. That way you can continue to build and develop your application even after releasing it, without interrupting your users.

Apple provides two primary types of SSL certificates: The APNs Development iOS certificate and the Apple Push Notification service SSL (Sandbox & Production) certificate. The Sandbox & Production certificate can be used on both test/sandbox and live/production apps, while the APNs Development iOS certificate may only be used with test/sandbox iOS apps.

When building your app using a development provisioning profile, set your Airship project to Test, and upload an APNs Development iOS or Apple Push Services SSL certificate. To push to an app built with a distribution provisioning profile (either with a release build in Xcode, ad hoc distribution, or the iTunes App Store), use a project that is designated as Live, and upload an Apple Push Services SSL certificate.


To support Catalyst apps in Xcode 11+, it’s necessary that your app be built with a provisioning profile that includes an Apple Developer certificate (for use in Xcode 11 or later) and the Mac capability listed under Enabled Capabilities:


Do not a) submit to the App Store or b) test notifications on an ad hoc build while your app’s code is pointing to an Airship app key that is set as Test. Test apps use different tokens that, when included in a push to a Live app, will fail and in many cases cause all other pushes to fail.

Always create a Live Airship project first, and make sure your application code is pointing to the live project’s app key. For more tips on what to check before you release your app, see the iOS Production Launch Checklist.

Get Your Certificate

  1. Log in to the Apple Developer Member Center, and navigate to Account » Certificates, IDs & Profiles, or use this direct link.

  2. In the left side menu, click Identifiers to open the identifiers section.


    If you have not already registered an iOS App ID, click the + button, select App IDs radio button and then click the Continue button:

    Next, fill out the Register an App ID form making sure to check the Push Notifications checkbox, and click the Continue button. Then you can skip to step 4.

  3. Click your app’s name from the list of App IDs. In the list of Application Services you will see a Push Notifications section with a configure button:

    Click the Configure button to continue to the Apple Push Notification service SSL Certificates section. The button will be labeled Edit if it has been configured previously.

    If the Configure/Edit button is not available, you may not be the team agent or an admin. The person who originally created the developer account is your team agent, and they will have to carry out the remaining steps in this section.

  4. Click the Create Certificate button to create a Production SSL Certificate. This will generate an Apple Push Notification service SSL (Sandbox & Production) certificate compatible with both the Production and Development environments.

    You should now see the Create New Certificate section to generate an Apple Push Notification service SSL (Sandbox & Production) certificate:

  5. Follow the instructions to create a certificate signing request in the Create New Certificate section, then click Continue after your certificate signing request is uploaded.

    You can now use the newly-created Certificate Signing request to generate the APNs Push SSL certificate. The next step requires the Download button to be active. You may need to reload the page if it is not yet active.

  6. Click the Download button, and save the file for use in the final step, Exporting your .p12 file.

Renewing Your Certificate

If you are renewing either your Test or Live Push SSL Certificate, follow the steps outlined above as if you were uploading the certificate for the first time. There is no need to revoke the previous certificate in order to make this change. There may be two production certificates at the same time, to allow you to continue using the old certificate while uploading the new one.


Send a test message to make sure that you’ve uploaded the correct, renewed certificate. If you upload the wrong certificate (a certificate not associated with your app and audience) and send a message, Apple will report that your audience is not related to your app, forcing Airship to remove those members of your audience. The Airship error console reports a Rejected Device Token error for each member of your audience when your certificate does not match your app.

Export as a .p12 File

You’re almost there. The final step before heading back over to the Airship application is to save your signing certificate as a .p12 file.

  1. Open the certificate you downloaded in the previous steps, which should open in the Keychain Access app. The certificate should be listed in My Certificates.

  2. Click the certificate in the list, then from the File menu, select Export Items….


    Be sure to select My Certificates under the Category menu on the lower left-hand side. If My Certificates is not highlighted, you will not be able to export the certificate as a .p12 file.

  3. Save the file in the Personal Information Exchange (.p12) format.

    You will be prompted to create a certificate password. Use this password in the next step: Configure the APNs Service.

Airship Steps

Configure your iOS project for push notifications in the Airship web portal.

Configure the APNs Service


Never use the same push certificate across multiple Airship app keys. You should also never use the same bundle ID across multiple app keys in the same environment (development or production). Not following these instructions can result in rejected device tokens and APNs feedback processed by the wrong app key. If you need to have a third app key for ad hoc builds (which also use Distribution-type push certificates), the bundle ID should be changed so you can use a different certificate, for example: “”.

These steps require the certificate and password you generated in the previous section.

  1. In Airship, go to Settings » Channels » Mobile App.

  2. Click Configure for iOS, enter the Certificate password, then Choose File and select the .p12 file exported in the completed Apple Steps.

  3. Click Save.

Your push certificate is now uploaded and ready for use. In the next section we will configure the Airship iOS SDK.

SDK Installation

The Airship SDK can be installed using CocoaPods, Carthage, or manually. Pick the option that makes the most sense for your project.


Before you begin, ensure that you have CocoaPods installed. If you are having troubles with CocoaPods, check out the troubleshooting guide.

$ gem install cocoapods

Update the podfile

The primary Airship pod includes the standard feature set and is advisable to use for most use cases. The standard feature set includes:

  • Core : Push messaging features including channels, tags, named user and default actions
  • MessageCenter : Message center
  • Automation : Automation and in-app messaging
  • ExtendedActions : Extended action functionality including the rate app action

The primary Airship pod includes the subspecs Airship/Core, Airship/MessageCenter, Airship/ExtendedActions and Airship/Automation - making it unnecessary to explicitly include these when using the primary pod.

Example podfile:


# Airship SDK
target "<Your Target Name>" do
  pod 'Airship'

  # Optional: uncomment to install the location subspec
  # pod 'Airship/Location'

The Airship pod also contains several subspecs that can be installed independently and in combination with one another when only a particular selection of functionality is desired:

  • Airship/Core : Push messaging features including channels, tags, named user and default actions
  • Airship/MessageCenter : Message center
  • Airship/Automation : Automation and in-app messaging
  • Airship/Location : Location including geofencing and beacons
  • Airship/ExtendedActions : Extended actions

Example podfile:


target "<Your Target Name>" do
  pod 'Airship/Core'
  pod 'Airship/MessageCenter'
  pod 'Airship/Automation'
  pod 'Airship/ExtendedActions'

  # Optional: uncomment to install the location subspec
  # pod 'Airship/Location'

Explicitly specify the tvOS platform in your podfile when targeting tvOS. Cocoapods automatic platform selection can also be used if the platform must be left unspecified.

When targeting tvOS - specify the platform in your podfile:

platform :tvos, '11.0'

Install the pods

$ pod install

After running pod install, an Xcode workspace (extension .xcworkspace) will be generated. Make sure to always open it instead of the project file (extension .xcodeproj) when building your projects.

Advanced Installation

Notification Extensions

Notification Service Extension

Create a new iOS target in Xcode

In Xcode, click the File menu, select New » Target…, then click the Notification Service Extension template.

Typically extensions are named with a suffix on the main application’s ID. In this example the bundle identifier would be com.urbanairship.sample.ExampleServiceExtension.

Check that your app’s target Embed App Extensions contains your newly created extension.

Then in your project’s Build Settings you must set the iOS Deployment Target to iOS 11+.

Notification Content Extension

See the content extension guide for instructions on setting up your content extension.

Install AirshipExtensions Dependency

Service and Content extensions depend on the AirshipExtensions pod. The AirshipExtensions pod consists of two subspecs:

  • AirshipExtensions/NotificationService : For use with service extension targets
  • AirshipExtensions/NotificationContent : For use with content extension targets

Example podfile:

target "<Your Service Extension Target Name>" do
  pod 'AirshipExtensions/NotificationService'

target "<Your Content Extension Target Name>" do
  pod 'AirshipExtensions/NotificationContent'


Specify the UrbanAirship-iOS-AppExtensions in your podfile and your newly created service extension as the target. Make sure to run pod install after modifying the podfile.

Example podfile:

target "SampleExtension" do
  pod 'UrbanAirship-iOS-AppExtensions'

Install using the following command:

$ pod install


Before you begin, ensure you have Carthage installed.

Adding the SDK framework to your application

Follow Carthage’s adding frameworks to an application instructions to add AirshipNotificationContentExtensions.framework and/or AirshipNotificationServiceExtensions.framework to their respective content or service extension targets.

If you are also using the Airship SDK, follow the instructions in the iOS SDK Guide.

Specify the Airship iOS SDK in your cartfile:

github "urbanairship/ios-library"

Verify Enable Modules and Link Frameworks Automatically are enabled in the project’s Build Settings.


Follow the same manual process to install AirshipExtensions.xcframework use the same method that you followed to install Airship.xcframework, except add AirshipNotificationContentExtension.xcframework and/or AirshipNotificationServiceExtension.xcframework to their respective content or service extension targets.

Modify the Extension


// Notification.swift

import AirshipNotificationServiceExtension

class NotificationService: UANotificationServiceEntension {

// NotificationService.h

@import AirshipNotificationServiceExtension;

@interface NotificationService : UANotificationServiceEntension


// NotificationService.m

@import Foundation;
import "NotificationService.h"

@implementation NotificationService


Delete all dummy source code for your new extension and inherit from UANotificationServiceEntension in NotificationService.

Update the Target’s Capabilities

Use Xcode to enable push notifications in the target’s Capabilities pane:

Enable background notifications that were introduced in iOS 7 by including the UIBackgroundModes key with the remote-notification value in your app’s Info.plist file. When viewing the plist in Xcode, UIBackgroundModes is displayed as Required background modes and remote-notification is displayed as App downloads content in response to push notifications.

You can also enable Background Modes and Remote notifications under the target’s Capabilities section:

Create Airship Config Options

Create a plist AirshipConfig.plist and include it in your application’s target. The default config will be loaded from the AirshipConfig.plist file if its included in the application target.

Example AirshipConfig.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <string>Your Development App Key</string>
  <string>Your Development App Secret</string>
  <string>Your Production App Key</string>
  <string>Your Production App Secret</string>

EU Cloud Site

If your app uses Airship’s EU cloud site, you will need to add that to AirshipConfig.plist.



The Airship SDK requires only a single entry point in the app delegate, known as takeOff. Inside your application delegate’s application:didFinishLaunchingWithOptions: method, initialize a shared UAirship instance by calling UAirship takeOff . This will bootstrap the SDK and look for settings specified in the AirshipConfig.plist config file.

Example app delegate changes
import Airship


func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {


    return true
@import Airship;


- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    [UAirship takeOff];

    return YES;

TakeOff must be called on the main thread and before application:didFinishLaunchingWithOptions: returns.

Send Your First Push Notification


Remote notifications are only available on a real device. You will not be able to send any notifications through APNs on a simulator.

At this point in the guide, if you followed all the steps above you should be ready to send a test push notification to verify everything is set up properly.

Before sending a push, you must enable user notifications. The SDK does not enable user notifications by default in order to avoid prompting the user for permissions before your app is ready to do so. But for a testing purposes, you can enable user notifications in the app delegate immediately after takeOff. You may also want to set default foreground presentation options to display the notification in the foreground. For more information on customizing push notifications or receiving callbacks, see Push Notifications.

Enable notifications for a quick test after calling takeOff
UAirship.push().userPushNotificationsEnabled = true
UAirship.push().defaultPresentationOptions = [.alert, .badge, .sound]
[UAirship push].userPushNotificationsEnabled = YES;
[UAirship push].defaultPresentationOptions = (UNNotificationPresentationOptionAlert |
                                              UNNotificationPresentationOptionBadge |

See Send Your First Message or our API reference for details on sending the first notification.

Deep Linking

Deep linking is a technique that allows an app to be opened to a specific UI or resource, in response to some external event. By implementing a deep linking strategy, your app becomes more responsive and capable of navigation to arbitrary content in response to push notifications, much in the same way that URLs can link you to specific pages on the Web.

With the Actions Framework, the Airship SDK now supports opening deep links from push notifications, and through Rich HTML content interactions. Because there is no one standard means of performing deep linking, this support only provides a consistent interface for triggering deep links. As an application developer, you still need to pick a deep linking strategy and perform some manual integration to be able to take advantage of this feature.

There are two common strategies for deep linking in iOS. For most applications, implementing the UADeepLinkDelegate will be the preferred strategy. This allows complete control over URL processing and sidesteps the need to register a unique URL scheme with the operating system. The alternative strategy is to register a unique URL scheme with the operating system and handle URL processing in the App Delegate’s openURL: callback.

Deep linking is most easily accomplished by implementing the deep link delegate’s receivedDeepLink:completionHandler: callback. This allow your app to process the URL provided in a UADeepLinkAction and use it to navigate to the desired view within your app.

- (void)receivedDeepLink:(NSURL *_Nonnull)url completionHandler:(void (^_Nonnull)(void))completionHandler {
    NSArray *pathComponents = url.pathComponents;

    if ([pathComponents containsObject:ViewStoryboardID]) {
        // Navigate to desired view

    // Call completion handler
func receivedDeepLink(_ url: URL, completionHandler: @escaping () -> ()) {
    let pathComponents = url.pathComponents

    if pathComponents.contains(ViewStoryboardID) {
      // Navigate to desired view

    // Call completion handler