Upgrade Guide

This topic contains the information you need to upgrade your mobile app to the latest Oracle Responsys Mobile App Platform Cloud Service SDK, starting with the 6.29.0 SDK through the most current release. It also, as needed, contains notes for updating your mobile app for iOS version changes.

We recommend that you also view the "Change Log" and "Release Notes" files for the SDK you are using. Those files are available from the PushIOManager_iOS SDK download page.

Upgrading your mobile app to the latest SDK

Important: When updating your mobile app to use the latest SDK, you must not only obtain the SDK, but you must also re-download the pushio_config.json and add it to the correct location in your mobile app. Oracle often updates the JSON file when new features are added.

To upgrade the SDK that your mobile app is using, do the following:

1. Obtain the SDK files from the PushIOManager_iOS SDK download page.

2. Download new versions of the pushio_config_debug.json (iOS Development) and pushio_config.json (iOS Distribution) from your app's settings pages in the Mobile App Console. See step 1.4 of the Step 1: Initial Setup section of the "Step-by-step Setup Instructions" topic.

3. Add the downloaded PushIOManager_IOS file, the pushio_config_debug.json file, and the pushio_config.json file to your project, as described in Step 2: Add Project Files of the "Step-by-step Setup Instructions" topic.

Currently supported platforms and languages

• Supported iOS versions: Oracle Responsys SDK 6.45.0 and later will support iOS 11.0 and later.

• Supported XCode versions: Oracle Responsys SDK 6.45.0 and later is supported by XCode 10.0.x and later.

• Supported languages: Objective-C and Swift.

PushIO SDK 6.39.0 to 6.40.0

Before You Begin: Please ensure that PushIO SDK 6.40 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

PushIO SDK 6.40.0 supports the following new functionality:

Geofence and Beacon Events API: Responsys now supports geofence and beacon events. The Responsys Push SDK has added a set of open APIs that enable app developers to raise entry and exit events for geofences and beacons. You can integrate with a geofence/beacon solution of your choice, or integrate with a native geofence/beacon solution.

Once implemented, marketers will be able to use geofence and beacon events in their program orchestrations in Responsys. These location-based events will be triggered when a mobile device user enters or exits a geofence or beacon zone.

To enable this feature:

• Your account must have the Responsys Events Interface feature enabled, which is a Controlled Availability feature. To request access to this feature, please contact your Customer Success Manager or log in to My Oracle Support and create a service request.

• Your organization's mobile apps must be built with the 19A Responsys Push SDK (version 6.40.0) or greater, when it becomes available.

• Your organization's mobile apps must also be integrated with your chosen solution for geofencing, or beacons, or both. Depending on your solution, integration may also involve setup by a Responsys user with access to the Responsys Events Interface.

Learn more:

• Geofences and beacons section in this guide
• Geofence and Beacon event variables in the Responsys Help Center
• Responsys Event Interface in the Responsys Help Center

mParticle Kit for Responsys SDK: As of 18D, the Oracle Responsys Push SDK supports an integration with mParticle through iOS and Android mParticle Kits, which serve as an integration layer between the Responsys and mParticle SDKs. If you use mParticle as a Customer Data Platform (CDP), this integration will enable you to forward events to mParticle for further analysis and processing.

To enable this integration: See mParticle's iOS Kit and Integration Instructions.

Support for conversion window for push conversions from mobile apps: Responsys already supports a Push Conversion event, which attributes conversions inside the app to the push campaign that led the app user into the mobile app. In 19A, this has been enhanced to allow mobile app developers and marketers to define the conversion window for push conversion events that occur from within the mobile app.

Marketers and mobile app developers will be able to define the concept of a conversion window that is applicable for their business. For example, they could define the conversion window to log a conversion only if the mobile app user makes the conversion within a certain number of days of opening the push notification. They could also define the conversion window such that a conversion is logged only once for every push notification opened.

To enable this feature: You must integrate your mobile app with the 19A Responsys Push SDK (version 6.40.0) when it becomes available. You must also modify your mobile app code as needed to define custom conversion behaviors. For more details, see the Engagements & Push Conversions section.

PushIO SDK 6.38.0 to 6.39.0

Before You Begin: Please ensure that PushIO SDK 6.39 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

PushIO SDK 6.39.0 supports the following new functionality:

Redesigned In-app Backend feature for supporting In-app campaigns: Oracle Responsys and the SDK have changed how In-app Messaging works for mobile apps built with the 6.39.0 and later SDK. Customers enabled for this feature can realize the following benefits:

• Size of the Rich HTML creative content used in In-app campaigns is no longer limited to 3.5 KB.

• In-app messages will be delivered to mobile apps on iOS devices, even if the mobile app has been "force quit" by the mobile app user. The SDK will fetch messages from Responsys every 5 minutes, store them on the device, and display them when triggered.

Implementation guidelines: If your organization has not yet integrated In-app Messaging and plans to implement a new In-app Messaging integration in its mobile app OR if your organization has already integrated In-app Messaging and are updating to SDK version 6.39.0 or later, you must use the "Redesigned In-app Backend" feature.

1. Request access to the "Redesigned In-app Backend" feature by contacting your Customer Success Manager or logging in to My Oracle Support and creating a service request. This feature is currently released under our Controlled Availability program.

2. You must build your mobile app with the 18D/6.39.0 SDK or greater.

3. You must turn on the feature in your code, using the SDK's setInAppFetchEnabled method.

Note for customers updating their mobile apps: If you update your mobile app to SDK version 6.39.0 or later but do not enable the "Redesigned In-app Backend" feature in your app, then this will impact the ability to target all mobile app users immediately once you finally enable the "Redesigned In-app Backend" feature. Mobile app users will have to update their app to the app version that implements "Redesigned In-app Backend" feature before In-app Messages can be delivered to them.

For more details, see In-app Messaging.

Message Center Direct: Mobile App Marketers will now have access to a new Mobile App Campaigns format, Message Center. The Message Center Campaign Designer will enable Marketers to send messages directly to their mobile app users’ in-app Message Centers, without requiring an accompanying Push notification. This enables Marketers to launch Message Center campaigns to mobile app users, even if users have opted-out of receiving Push notifications. Currently, mobile apps fetch Message Center messages at 2-hour intervals, so Marketers will find it best suited for communications that are not time-sensitive.

To enable this feature:

1. Request access to the Message Center feature by contacting your Customer Success Manager or logging in to My Oracle Support and creating a service request. This feature is currently released under our Controlled Availability program.

2. For best results and performance of Message Center, your mobile app must use the Oracle Responsys Mobile App Platform Cloud Service SDK version 6.39 (18D) or later. The 6.39 version of the SDK contains key bug fixes for this feature. Oracle recommends that your mobile app always use the latest SDK.

3. You must turn on Message Center in your code, using the SDK's setMessageCenterEnabled method. This applies even if you are upgrading from an older SDK version to SDK version 6.39.0 or later.

For more details, see the message center section for iOS.

PushIO SDK 6.37.0 to 6.38.0

Before You Begin: Please ensure that PushIO SDK 6.38 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

PushIO SDK 6.38.0 supports the following new functionality:

New Standard Interactive Notifications: Marketers now have access to 17 new Standard Interactive Notifications when they create Push campaigns. For the interaction buttons to be present in a Push notification, the mobile app associated with the campaign must be built with the 18C/6.38.0 SDK or greater.

For more details, see Interactive Notifications.

Mobile App Console Test Push supports multiple device IDs: You can now send a single test push from the Mobile App Console to up to 10 device IDs. For details, see the Test Apps topic.

SDK crash reporting: The SDK is capable of reporting crashes that happen within the SDK back to Responsys. This feature is enabled by default. You can use the setCrashLoggingEnabled method to disable or enable this feature. For more details, see Debugging & Logging.

PushIO SDK 6.35.0 to 6.37.0

Before You Begin: Please ensure that PushIO SDK 6.37 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

This release supports features released for Oracle Responsys 18B. We recommend that customers use the latest SDK version, but there is no need to upgrade if the SDK updates are not applicable for your mobile app.

Note: Although the Oracle Responsys product has adopted a new naming convention for its quarterly product updates, the SDK versions will retain the 6.x numbering system. However, the PushIO SDK version may skip numbers in its version naming sequence. For example, the SDK version moved from 6.33.0 to 6.35.0 in 18A, and it is 6.37.0 in 18B.
PushIO SDK 6.37.0 supports the following new functionality.

Important Message Center updates: In the 18B update, the interaction between the mobile app SDK and the Responsys server has changed. The Oracle Responsys Mobile App Cloud Platform SDK (Push SDK version 6.37.0 onwards) retrieves "Message Center" messages from Responsys at fixed intervals every time a mobile app is launched. The Push SDK stores retrieved messages locally, and they are served from the local storage on the device to your mobile app on demand. Mobile apps must also use an additional method, fetchRichContent, to get the rich HTML content for individual Rich Push messages.

To learn more about implementing this feature for your iOS app, see Message Center on iOS.

Cross-channel conversion tracking: This optional new feature enables marketers using Responsys to evaluate how effective their marketing campaign is in driving a particular post-clickthrough action, such as making a purchase. For this feature to work, Marketers must include tracked links to the mobile app in the link tables for their Email campaigns. Mobile App Developers must provide the app links to the Marketers. They must also configure the mobile app to record the click, wait for the conversion action, and then send the conversion to Responsys. To learn more about implementing this feature for your mobile app, see Cross-channel Conversion Tracking.

Note: Although the Oracle Responsys product has adopted a new naming convention for its quarterly product updates, the SDK versions will retain the 6.x numbering system. However, the PushIO SDK version may skip numbers in its version naming sequence. For example, the SDK version moved from 6.33.0 to 6.35.0 in 18A, and it is 6.37.0 in 18B.

PushIO SDK 6.33.0 to 6.35.0

Before You Begin: Please ensure that PushIO SDK 6.35 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

Note: Although the Oracle Responsys product has adopted a new naming convention for its quarterly product updates, the SDK versions will retain the 6.x numbering system. However, the PushIO SDK version may skip numbers in its version naming sequence. The upcoming SDK version is moving from 6.33.0 to 6.35.0. The next planned, major release will be SDK version 6.37.0.
PushIO SDK 6.35.0 supports the following new functionality:

• Interactive Notifications: When Marketers design Push Campaigns in Responsys, they now have an option to add greater interactivity to their Push Notifications through Interactive Notifications. Interactive Notifications enable Marketers to add actionable buttons to their Push Notifications, and they allow mobile app users to interact with Push notifications. If you need buttons other than those provided in the Standard Interactive Notifications, Responsys supports adding Custom Interactive Notifications for mobile apps. To learn more about implementing this feature for your mobile app, see Managing Interactive Notifications.

• Customized User Experience for Links and Calls-to-action in Rich Push, In-app Messages: This optional new feature gives you more control of how these types of links are handled. For example, if you want these links (including HTTP web links) to all be displayed within the mobile app, you can now do so. You can also fix the user experience of being bounced off a browser before being taken to a destination URL. To learn more about implementing this feature for your mobile app, see Customizing UX for Destination URLs

Note: Although the Oracle Responsys product has adopted a new naming convention for its quarterly product updates, the SDK versions will retain the 6.x numbering system. However, the PushIO SDK version may skip numbers in its version naming sequence. The SDK version is moving from 6.33.0 to 6.35.0. The planned SDK version for 18B will be 6.37.0.

PushIO SDK 6.32.0 to 6.33.0

Before You Begin: Please ensure that PushIO SDK 6.33 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

PushIO SDK 6.33.0 supports the following new functionality:

Separate Opt-in for Push (Pre-permission Messaging): If you want to delay the system prompt for push notification permission but want to register the application with SDK separately, now there are additional/separate methods provided to achieve it. See the Separate Opt-in for Push (Pre-permission Messaging) section in the Step-by-Step Setup Instructions topic for more details about these methods.

Multiple Message Centers: Responsys 6.33 supports multiple Message Centers for mobile apps. See the Message Center topic for more details.

Logging changed for Device ID: In previous versions of the SDK, when developers needed to find the device ID of their test device, they needed to search for the di attribute in the log files and use the value shown for testing. In 6.33 and later, you must search the log for the text "Device ID:" and use the value displayed. The Device ID is printed for every log level, even when SDK console logging is disabled.

PushIO SDK 6.29.2 to 6.32.0

Before You Begin: Please ensure that PushIO SDK 6.32 for iOS is available before using this section. You can verify the current version by going to the iOS SDK download page.

PushIO SDK 6.32.0 supports features released in Responsys versions 6.31 and 6.32. The sections below provide information about migrating your mobile application from using the 6.29.2 SDK to the 6.32.0 SDK. Migration will require changes to your mobile application's setup, code changes, and some refactoring for deprecated methods.

We recommend that customers use the latest SDK version, but there is no need to upgrade if the SDK updates are not applicable for your mobile app. If you plan to use the Message Center feature, your mobile app must be built with the 6.32.0 PushIO SDK.

Supported platforms and languages

Supported iOS versions: PushIO SDK 6.32.0 and later will support iOS 8.0 and later.

Supported XCode versions: PushIO SDK 6.32.0 and later is supported by XCode 8.3.2 and later.

Supported languages: PushIO SDK 6.32.0 and later will support Objective-C and Swift.

Setup Changes

For 6.32.0, make the following changes to your mobile application setup.

[1.] Add the SQLite framework to your application target:

6.32.0 uses sqlite to store the events (that is, register, engagement, unregister) and sync later. Your mobile application needs to add the sqlite3.0.tbd framework in your application target.

To add the framework:

1. Open .xcodeproj in Xcode.
2. Select your project from left pane.
3. Select your application target.
4. Select the General tab.
5. Scroll down to Linked Frameworks and Libraries.
6. Click + and then select libsqlite3.0.tbd from the list.

[2.] Add the UserNotifications framework:

6.32.0 works with the UserNotifications framework APIs. Your mobile application needs to add the UserNotifications framework.

To add the framework:

1. Open .xcodeproj in Xcode.
2. Select your project from left pane.
3. Select your application target.
4. Select the General tab.
5. Scroll down to Linked Frameworks and Libraries.
6. Click + and then select UserNotifications.framework from the list.

[3.] Enable the Push Notifications capability:

Your mobile application needs to add the Push Notifications capability, which you can do from the Capabilities tab of your application settings.

Ensure that when you enable Push Notifications:

• Add the Push Notifications feature to your app id.

• Add the Push Notifications entitlement to your entitlements file

Code Changes

For 6.32.0, make the following changes to your mobile application code.

[1.] Add Debug vs Release configuration in AppDelegate.m:

Mobile apps now control whether configuration is loaded from either pushio_config_debug.json or pushio_config.json.
Applications must set the configType to let the SDK read the suggested configuration file:

• Objective-C
• Swift

#ifdef DEBUG
    [PushIOManager sharedInstance].configType = PIOConfigTypeDebug; //load pushio_config_debug.json
#else
    [PushIOManager sharedInstance].configType = PIOConfigTypeRelease; //load pushio_config.json
#endif						

#if DEBUG
    PushIOManager.sharedInstance().configType = PIOConfigType.debug; //load pushio_config_debug.json
#else
    PushIOManager.sharedInstance().configType = PIOConfigType.release;//load pushio_config.json
#endif				

IMPORTANT: If your mobile app does not set the configType value, the app will not select a configuration file (pushio_config_debug.json or pushio_config.json). Without the configuration file, your app will be unable to communicate with the server, and critical functions will fail (register, fetch messages, track engagements, and the like).

[2.] Enable logging in AppDelegate.m:

With 6.32.0, setDebugLevel is discontinued. To enable logging, use the enableLogging and setLogLevel methods. Use disableLogging to disable logging.

• Objective-C
• Swift

#ifdef DEBUG
    [[PushIOManager sharedInstance] enableLogging:YES];
    [[PushIOManager sharedInstance] setLogLevel:PIOLogLevelInfo]; //PIOLogLevelWarn or PIOLogLevelError
#else
    [[PushIOManager sharedInstance] disableLogging];
#endif						

#if DEBUG
    PushIOManager.sharedInstance().enableLogging(true);
    PushIOManager.sharedInstance().setLogLevel(PIOLogLevel.info); //PIOLogLevel.warn or PIOLogLevel.error
#else
    PushIOManager.sharedInstance().disableLogging()
#endif				

3.] Implement UserNotifications framework support: Implement the UNUserNotificationCenterDelegate method in your AppDelegate.h and AppDelegate.m files, as shown below:

• Objective-C
• Swift

//In AppDelegate.h
#import <UserNotifications/UserNotifications.h>
@interface AppDelegate : UIResponder <UIApplicationDelegate,UNUserNotificationCenterDelegate>
@end

//In AppDelegate.m
//Set the userNotificationCenter delegate, preferably in didFinishLaunchingWithOptions
[UNUserNotificationCenter currentNotificationCenter].delegate= self;

-(void) userNotificationCenter:(UNUserNotificationCenter *)center
    didReceiveNotificationResponse:(UNNotificationResponse *)response
             withCompletionHandler:(void(^)())completionHandler{
    [[PushIOManager sharedInstance] userNotificationCenter:center didReceiveNotificationResponse:response withCompletionHandler:completionHandler];
}

-(void) userNotificationCenter:(UNUserNotificationCenter *)center
           willPresentNotification:(UNNotification *)notification
             withCompletionHandler:(void (^)(UNNotificationPresentationOptions options))completionHandler{
    [[PushIOManager sharedInstance] userNotificationCenter:center willPresentNotification:notification withCompletionHandler:completionHandler];
}						

// didFinishLaunchingWithOptions
if let options = launchOptions {
    PushIOManager.sharedInstance().didFinishLaunching(options: options)
}

// didReceiveNotificationResponse
@available(iOS 10.0, *)
func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {
    PushIOManager.sharedInstance().userNotificationCenter(center, didReceive: response, withCompletionHandler: completionHandler)
}

// willPresentNotification
@available(iOS 10.0, *)
func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
    PushIOManager.sharedInstance().userNotificationCenter(center, willPresent: notification, withCompletionHandler: completionHandler)
}				

Deprecated Methods

This section lists the methods are deprecated in the 6.32.0 SDK, and it provides instructions for how to adapt your mobile app code for these changes.

PushIOManagerDelegate

• You no longer need to set PushIOManagerDelegate for registration callbacks, because completionHandler will be called for respective callbacks.

registerWithPushIO and registerForAllRemoteNotificationTypes

• registerWithPushIO and registerForAllRemoteNotificationTypes are deprecated. Use following steps to register:

[1.] Ensure that your application implements Configure SDK with a valid APIKey and accountToken (Copy these values from the pushio_config.json file, or pushio_config_debug.json file if the app is in debug mode, as shown in step 7.4 in the Step-by-Step section. Pass nil for accountToken if it's not applicable.):

• Objective-C
• Swift

NSError *error = nil;

    [[PushIOManager sharedInstance] configureWithAPIKey:API_KEY accountToken:ACCOUNT_TOKEN error:&error];
    if(nil == error){
        NSLog(@"SDK Configured Successfully");
    }else{
        NSLog(@"Unable to configure SDK, reason: %@", error.description);
    }
        						

var apiKey : String
var accountToken : String
//FIXME: correct the apiKey and accountToken values
#if DEBUG
    apiKey = "DEBUG_APIKEY";//Copy the apiKey value from pushio_config_debug.json
    accountToken = "DEBUG_ACCOUNT_TOKEN";//Copy the accountToken value from pushio_config_debug.json. Assign nil if no value available.
#else
    apiKey = "RELEASE_APIKEY";//Copy the apiKey value from pushio_config.json.
    accountToken = "RELEASE_ACCOUNT_TOKEN";//Copy the accountToken value from pushio_config.json. Assign nil if no value available.
#endif

do{
    try PushIOManager.sharedInstance().configure(withAPIKey: apiKey, accountToken: accountToken)
}catch{
    print("Unable to configure, reason:\(error)")
}				

[2.] Once the SDK is configured successfully, register as follows:

• Objective-C
• Swift

[[PushIOManager sharedInstance] registerForAllRemoteNotificationTypes:^(NSError *error, NSString *deviceToken) {
    if (nil == error) {
        NSError *regTrackError = nil;
        [[PushIOManager sharedInstance] registerApp:&regTrackError completionHandler:^(NSError *regAppError, NSString *response) {
            if (nil == regAppError) {
                NSLog(@"Application registered successfully!");
            }else{
                NSLog(@"Unable to register application, reason: %@", regAppError.description);
            }
        }];
        if (nil == regTrackError) {
            NSLog(@"Registration locally stored successfully.");
        }else{
            NSLog(@"Unable to store registration, reason: %@", regTrackError.description);
        }
    }
}];
      						

// Requests a device token from Apple
PushIOManager.sharedInstance().register(forAllRemoteNotificationTypes: { (regTrackError, deviceToken) in
    if (regTrackError == nil)
    {
        print("Device Token: \(deviceToken)")
        do{
            // Register application with SDK.
            try PushIOManager.sharedInstance().registerApp(completionHandler: { (regError, response) in
                if (regError == nil)
                {
                    print("Registration successful")
                }
                else
                {
                    print("Unable to register, reason: \(regError)")
                }
            })
        }catch{
            print("Unable to track registration locally, reason: \(error)")
        }
    }
})				

unregisterFromPushIO

• unregisterFromPushIO is deprecated. Call unregisterApp instead:

• Objective-C
• Swift

NSError *error = nil;
[[PushIOManager sharedInstance] unregisterApp:&error completionHandler:^(NSError *error, NSString *response) {
    if (nil == error) {
        NSLog(@"Unregister successful.");
    }else{
        NSLog(@"Failed to unregister, reason: %@", error.description);
    }
}];						

let unregError: Error? = nil
try? PushIOManager.sharedInstance().unregisterApp(completionHandler: {(_ error: Error?, _ response: String?) -> Void in
    if nil == error {
        print("Unregister successful.")
    }
    else {
        print("Failed to unregister, reason: \(error!.localizedDescription)")
    }
})
if nil != unregError {
    print("Error occurred while unregister, reason: \(unregError!.localizedDescription)")
}				

unregisterUserID

• unregisterUserID is deprecated. Instead, call registerUserID and pass nil as the argument, as follows:

• Objective-C
• Swift

isRegisteredForUserID

• isRegisteredForUserID is deprecated. Instead, call getUserID and compare it to the application, as follows:

• Objective-C
• Swift

registeredUserID

• registeredUserID is deprecated. Instead, call getUserID, as follows:

• Objective-C
• Swift

pushIOUUID

• pushIOUUID is deprecated. Instead, call getDeviceID, as follows:

• Objective-C
• Swift

pushIOAPIKey

• pushIOAPIKey is deprecated. Instead, call getAPIKey, as follows:

• Objective-C
• Swift

pushIOAccountToken

• pushIOAccountToken is deprecated. Instead, call getAccountToken, as follows:

• Objective-C
• Swift

PushIO SDK 6.29.1 to 6.29.2

PushIO SDK 6.29.2 involves changes to Device ID persistance, which now uses the iOS Keychain. Persisting the Device ID ensures that it will stay the same across re-installs of an app on the same device, so that Responsys can use the known Device ID to update the existing App Channel List record instead of creating a new one each time.

No specific steps are required to migrate from 6.29.1 to 6.29.2.

PushIO SDK 6.29.0 to 6.29.1

PushIO SDK 6.29.1 supports compatibility with iOS 10 GM. No specific steps are required to migrate from 6.29.0 to 6.29.1, if your app does not support iOS10.

iOS 10 Support Notes

This section provides instructions for the two changes required for supporting iOS 10. Before you begin, ensure that you are using Push SDK 6.29.1 or later.

Setup change

On the application settings Capabilities tab, ensure that Push Notifications is enabled.

Code change for notification support

The UserNotifications framework is not supported in the most recent versions (6.29.0, 6.29.1) of the Push SDK. To support notifications for both iOS 10 and earlier versions, the application must override the following didReceiveRemoteNotification methods, as shown below. (The first method is required specifically for iOS 10, and the second method is required for supporting earlier iOS versions.)

-(void)application:(UIApplication *)application  didReceiveRemoteNotification:(NSDictionary *)userInfo{
[[PushIOManager sharedInstance]  didReceiveRemoteNotification:userInfo];
}

- (void)application:(UIApplication *)application  didReceiveRemoteNotification:(NSDictionary *)userInfo  fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
{
    [[PushIOManager sharedInstance]  didReceiveRemoteNotification:userInfo  fetchCompletionResult:UIBackgroundFetchResultNewData  fetchCompletionHandler:completionHandler];
}

Push SDK Version Numbering Change

Starting in September 2016, the Oracle Push Cloud Service SDK version numbering scheme will change from 2.13.x to 6.29.x. This change aligns the SDK version number with that of its parent product. The latest SDK release for iOS is always available from the iOS SDK download page.

No specific steps are required to migrate from 2.13.4 to 6.29.0.

Moving from iOS8 to iOS9

• There is one required change to get inAppMessaging working.
• There is one optional change to get location (background mode) working.
• App Transport Security, which improves secured connections between app and server, impacts apps compiled with iOS9.

inApp Messaging (Required)

As you use inAppMessaging to open the inApp dialogs in the application, you will need to update your application’s plist to handle the changes in canOpenURL. This is described in the Apple Developer video topic, Privacy and Your App.

If you're recompiling with iOS SDK 9.0, add the following to your application’s plist (replace _pio-PUSH_APP_ID_ with your own App ID):

<key>LSApplicationQueriesSchemes</key>  
<array>  
    <string>
        pio-PUSHIO_APP_ID
    </string>  
</array>

OR add visually (in plist) by adding LSApplicationQueriesSchemes as an array and add _pio-PUSHIO_APP_ID as first item in it (replace pio-PUSH_APP_ID_ with your own App ID):

Location Access (Optional)

If your application accesses the location capability of the PushIO SDK, you must add the following into your plist:

<key>allowsBackgroundLocationUpdates</key>  
<true/>

OR add visually (in plist) by adding allowsBackgroundLocationUpdates as Boolean and set the value to YES:

App Transport Security (ATS)

If you compile your app with iOS SDK 9.0, you will be affected by a new security feature called App Transport Security (ATS), which enforces best practices for secure network connections - notably, TLS 1.2 and forward secrecy. Apple offers some configuration options to leverage ATS where possible, while disabling it in places where you cannot support it.

If your In-App message or Push message contains a URL, it needs to adhere to the ATS guideline. If ATS guidelines cannot be adhered to at that URL, you can consider granting that URL a policy exception. If ATS guidelines cannot be followed, respective exceptions must be added to your your app's Info.plist.

For information about App Transport Security including details about the different exceptions which are possible, see the NSAppTransportSecurity topic on the Apple's Developer site.

To check your SSL cert details and compare them against ATS guidelines, you can use the following SSL Server Test utility: https://www.ssllabs.com/ssltest/.

Moving from iOS 7 to iOS 8

• There is one required change in code for configuring notification settings and obtaining device tokens for APNs.

• There are three optional steps if using location, backgrounding modes (for pushing "silent" data without alerts), and for tapping into Apple's "Category" feature introduced in iOS 8.

Steps for Upgrading SDKs:

[1] Make changes to your AppDelegate.m & Push IO SDK Callbacks:

Basic Push:

Use this method if utilizing basic push (without iOS's new Category feature) under the didFinishLaunchingWithOptions method:

[[PushIOManager sharedInstance] registerForAllRemoteNotificationTypes];

This callback will determine if the device is iOS 8 or below versioning, and assign notification settings accordingly. The above method should replace the previous APNs token settings code already in your app(s):

// Requests a device token from Apple
[[UIApplication sharedApplication] registerForRemoteNotificationTypes:UIRemoteNotificationTypeAlert     | UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound];

Advanced Push (Optional) - If Using Apple's "Category" Functionality

NOTE: The below code is just an example of using Apple's Category functionality in iOS 8. There are a few ways of setting these notifications up. We suggest you read up on the new functionality directly from Apple, as well: Apple Dev: "What's New in iOS Notifications".

    if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0) {

    UIMutableUserNotificationAction *viewAction = [[UIMutableUserNotificationAction alloc] init];
    viewAction.identifier = @"ACCEPT";
    viewAction.title = @"Accept";
    viewAction.activationMode = UIUserNotificationActivationModeForeground;
    viewAction.destructive = NO;

    UIMutableUserNotificationAction *dismissAction = [[UIMutableUserNotificationAction alloc] init];
    dismissAction.identifier = @"DECLINE";
    dismissAction.title = @"Decline";
    dismissAction.activationMode = UIUserNotificationActivationModeBackground;
    dismissAction.destructive = YES;

    UIMutableUserNotificationCategory *category = [[UIMutableUserNotificationCategory alloc] init];
    category.identifier = @"firstcategory";
    [category setActions:[NSArray arrayWithObjects:viewAction, dismissAction, nil] forContext:UIUserNotificationActionContextDefault];

    NSSet *test = [NSSet setWithObjects:category, nil];

    UIUserNotificationType types = UIUserNotificationTypeBadge | UIUserNotificationTypeSound | UIUserNotificationTypeAlert;
    UIUserNotificationSettings *mySettings = [UIUserNotificationSettings settingsForTypes:types categories:test];
    [application registerUserNotificationSettings:mySettings];
    [application registerForRemoteNotifications];
} else {

    // To accommodate for OS below iOS 8

    [application registerForRemoteNotificationTypes:
     UIRemoteNotificationTypeBadge |
     UIRemoteNotificationTypeAlert |
     UIRemoteNotificationTypeSound];
}

[2] (Optional) Configure the Handling of Action IDs for iOS 8's New "Category" Functionality by adding the Action ID handler in your AppDelegate.m file:

- (void)application:(UIApplication *)application  handleActionWithIdentifier:(NSString *)identifier  forRemoteNotification:(NSDictionary *)userInfo  completionHandler:(void (^)())completionHandler
{

   if ([identifier isEqualToString:@"ACCEPT"])
    {
        // Perform Accept Action
    }

    if ([identifier isEqualToString:@"DECLINE"])
    {
    // Perform Decline Action
    }

    [[PushIOManager sharedInstance]  handleActionWithIdentifier:identifier  forRemoteNotification:userInfo  completionHandler:completionHandler];
    completionHandler();
}

[3] (Optional) Update your Info.Plist to Comply with Apple Changes to Location

Add one of two lines to your Info.plist for necessary Location support, depending on the use-case of your application:

NSLocationWhenInUseUsageDescription - "Location Description When In Use"

or

NSLocationAlwaysUsageDescription - "Location Description Always In Use"

For example,

[4] (Optional, Recommended) Background Push Callbacks

    // This method is called for background-only pushes  
     - (void)application:(UIApplication *)application  didReceiveRemoteNotification:(NSDictionary *)userInfo  fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
     {
    // You can pass this to PushIO either before or after you do any processing  
    [[PushIOManager sharedInstance]  didReceiveRemoteNotification:userInfo];

    // Use whatever makes sense for your application  
    completionHandler(UIBackgroundFetchResultNewData);
     }

Similar to Location changes in the .plist, add a mandatory background key/pair to your Info.plist file for necessary background push support:

UIBackgroundModes - remote-notification

And be sure "Remote Notifications" is selected in the Capabilities section in your app's settings (Target --> Capabilities --> Background Modes):