Last modified May 22, 2020 by Shelly Wolfe


Swrve is a single integrated platform that delivers everything you need to drive mobile engagement and create valuable customer relationships on mobile.
The Swrve native iOS SDK enables your app to use all of these features. This guide contains all the information you need to integrate the SDK into your app.
The code examples in this guide refer exclusively to Swrve iOS SDK version 6.0+. If you are upgrading from an SDK older than version 6.0, please also refer to the SDK release notes to review major changes made to the SDK methods and APIs in all major versions.


  • The Swrve iOS SDK supports iOS 10 and later but is able to handle older OS versions with a dummy SDK.
  • OTT – The Swrve iOS SDK includes support for tvOS. There are no additional integration steps, however if you use Carthage or manually install the SDK, you must specify the platform. For more information, see the relevant section under Installing the SDK.
  • Ensure you have the latest version of Xcode.
  • If you’re developing your app in Swift, we recommend upgrading to the latest SDK version to prevent compatibility issues. For more information, see Integrating the iOS SDK using Swift.
  • The App ID and API Key for your app. This information is available in Swrve on the Integration Settings screen (on the Settings menu, select Integration settings).


The Swrve SDK references the following frameworks:

  • CFNetwork.framework
  • StoreKit.framework
  • Security.framework
  • QuartzCore.framework
  • CoreTelephony.framework
  • UIKit.framework
  • MessageUI.framework
  • CoreLocation.framework
  • AVFoundation.framework
  • CoreText.framework
  • UserNotificationsUI.framework
  • UserNotifications.framework

If you want to exclude the push notification feature, you can remove the following frameworks by adding an associated preprocessor macro (for more information, see How do I exclude optional iOS frameworks?):

  • UserNotificationsUI.framework
  • UserNotifications.framework

Automatic Reference Counting

If your Xcode project does not use Automatic Reference Counting (ARC), and you’re manually installing the SDK (that is, not using CocoaPods), you must enable ARC for each file in the Swrve SDK.

Installing the SDK


Step 1: In your project’s Podfile, add the following dependency:

Step 2: Run the following command to install the new dependency:


Step 1: In your project’s Cartfile, add the following dependency:

Step 2: Run the following command to install the new dependency:

Compiling for tvOS

If you are compiling for tvOS, ensure that you’re running version 28 of Carthage or above and specify the platform as follows:

Manual installation

Step 1: Download the SDK from the GitHub public repository or download a .zip file of the latest iOS SDK.

Step 2: Unzip the iOS SDK, copy the contents of the SDK folder into your Xcode project and link against the frameworks listed above.

Installing the SDK in a Swift project

If you’re manually installing the SDK in a Swift project, you must build a project bridging-header.h file that includes the following line:

Compiling for tvOS

If you are compiling your app to run on both iOS and tvOS, ensure you add the SwrveConversation-tvOS.storyboard resource to your app’s target membership in Xcode. Otherwise, exclude it to run on only iOS.

Initializing the SDK

Depending on your data requirements, Swrve stores all customer data and content in either our US or EU data centers. If your app uses EU data storage and URL endpoints (that is, you log into the Swrve dashboard at, include the EU stack information in the example below. If you have any questions or need assistance configuring the SDK for EU data storage, please contact

Step 1: To initialize the SDK, in your App Delegate source file (usually named AppDelegate.m), add the following code snippet to the didFinishLaunchingWithOptions method. Replace <app_id> and <api_key> with your app ID and API key.



The DEBUG macro should be present in the Preprocessor Macros by default. If not present, please add DEBUG=1 to your debug configuration under Preprocessing > Preprocessor Macros > Debug.

Step 2 (Optional): As of iOS 9, by default all communications between the app and its backend or the web should use HTTPS. (See the App Transport Security section in Apple’s What’s New in iOS 9.0 guide.) Swrve’s API URL endpoints are now all HTTPS-capable and the API calls default to HTTPS. However, if you’re planning to use YouTube videos as content in your Conversations, add an Application Transport Security exception to your <App>-Info.plist.

This is needed, as even HTTPS YouTube links use non-secure endpoints that keep changing over time.

Step 3 (Optional): If you are planning to use or ask for location tracking permission, add the following keys to your <App>-Info.plist if not already there. Use the value to explain to your users why your app requires the various location permission. For example, “Goaletics uses your location to inform you about deals and events in your area.”

  • NSLocationAlwaysUsageDescription – explains why the app requires access to the user’s location at all times (for apps supporting iOS 10 and earlier).
  • NSLocationWhenInUseUsageDescription – explains why the app requires the user’s location information when running in the foreground.
  • NSLocationAlwaysAndWhenInUseUsageDescription – explains why the app requires access to the user’s location at all times.

The project is now ready to compile and run in the iOS simulator.

By default, the Swrve iOS SDK enables you to track important metrics and run in-app messages and Conversations campaigns. To make use of additional Swrve features, such as user identity, push notifications, and advanced metrics tracking, complete the following sections as required.

Advanced initialization mode

As of iOS SDK version 6.3, there are two modes for initializing the SDK: AUTO and MANAGED. In AUTO mode, the SDK is automatically initialized as outlined in the previous section. However, if you want to delay the point at which the SDK starts tracking and sending events for a particular user, set the initMode property in the SwrveConfig to MANAGED.  For example, you might want to use a custom ID as the Swrve user ID and not start sending events or targeting a customer until they’ve confirmed their user ID (that is, they’ve logged in). If you use MANAGED mode, the SDK will delay tracking by default until the user ID is set at least once via the start API.

Do not use email or other personally identifiable information (PIIs) for the custom user ID, as this could be used to compromise your app or integration. Instead, use an internal ID that is only known to your CRM and cannot be linked back to a user outside of your system.

Objective C


If you want to delay starting the SDK every time the SDK is initialized (even if you’ve started it in a previous session), then set the managedModeAutoStartLastUser configuration property to false.

Objective C


Constraints and considerations

Depending on the initialization mode you choose to use, there are certain limits or nuances you should be aware of:

  • In MANAGED mode, you can’t call the Identify API. If you try to call the Identify API, it will result in a fail fast exception.
  • In AUTO (default) mode, you can’t call the following APIs. If you try to call them, it will result in a fail fast exception:
    • start()
    • start(userId)
  • In-app campaigns linked to a push notification are blocked in configurations where:
    • initMode is MANAGED
    • managedModeAutoStartLastUser is false
  • Push notification engaged events are always tracked against the last known user ID (even if initMode is MANAGED and managedModeAutoStartLastUser is false).
  • Use the [SwrveSDK started] API to check if the SDK is started before calling regular APIs when initMode is MANAGED and managedModeAutoStartLastUser is false.

User identity

Swrve supports an Identify API to find preexisting user identities that an app has logged either on a single device or multiple devices. You can now identify users and then track and target them safely across multiple devices, platforms, and channels. For more information, see Tracking your users with Swrve User Identity.

The external ID is a non-discoverable key that identifies your user across multiple channels and platforms. Emails or other personally identifiable information (PIIs) are not accepted as external user IDs, they will be rejected on the server side. Before you implement the Identity service, please consult with your Customer Success Manager at for some guidance on best practices to follow in your integration.


Initialize SwrveSDK as normal in the AppDelegate:

Objective C


When you are ready, call the Identity API with your external user ID:

Objective C


If the call fails, then the user will not be correctly linked on the Swrve backend system, which may affect reporting and audiences where the user is logging in on multiple devices. We recommend not queuing or sending events until the identify call completes.

Push notifications

Use Swrve’s push notification campaigns to send personalized messages to your app users while they’re outside of your app or send silent background app updates. For more information, see Intro to push notifications.

Push notification campaigns are not currently supported on OTT platforms.

This section covers how to integrate basic Swrve push notifications. To include rich media content and custom buttons in your push notifications, you must also complete the steps outlined in the Rich media push notifications section.

Push notifications are disabled by default. To enable them, set SwrveConfig.pushEnabled to YES. In addition, you must tell the Swrve SDK when your app receives a push notification (this is required for push notification reporting in the Swrve service).

For Actionable Notifications on iOS 10+, you must use the notification categories in UNNotificationCategory

Your app must also handle the following two situations:

  • The app is launched from a push notification.
  • The app receives the push notification while running.



The remainder of the initialization process depends on how you want to request permission from the user to accept push notifications.

Timing the device token (push authorization) request

When a user first installs a push-enabled app, the app requests the latest device token for push notifications. This triggers a permission request to the user to accept push notifications from the app. Swrve has built-in functionality to manage the timing of this request. There are two options:

  • Start of the first session (default configuration) – This is the simplest option and requires no additional code changes.
  • When one of a list of events is triggered – To request permission when certain events are triggered, add the event names to SwrveConfig.PushNotificationEvents when you initialize the SDK. For example:

Objective C


If a user never triggers these events, they will never be available for push notifications, so select events that are most likely to be triggered by all but the most transient of users.

For more information about uploading device tokens, see How do I upload push device tokens?

Provisional authorization for push

In iOS 12, Apple added a feature for provisional authorization of push notifications. This feature enables you to send push notifications as soon as a user opens your app for the first time, without requiring the user to opt-in. The notification is delivered directly to the device’s Notification Center and when the user views the notification, the message automatically includes a built-in prompt asking if they want to continue to receive notifications.

By default, the Swrve SDK requests full push permission the first time the user launches your app. To implement provisional authorization, set different events for both the provisional and full authorization in your SDK configuration.

Objective C


QA testing push notification authorization

Apple only asks for permission to receive push notifications once per app, under normal circumstances. As a result, when you want to test your push notification integration on a QA device, you must reset the iOS push permissions to test the different timing configurations for push permissions outlined above. For more information, see How do I reset iOS permissions?

Configuring silent notifications

The purpose of a silent notification is to refresh your app’s data when it is running in background, for example, a content update. You should never call the SDK from a silent notification. Note, iOS does not permit silent notifications to wake up the app if it is completely closed (that is, a user has double-clicked the home button and swiped up to close the app). If the app is closed, you can only update the badge number.

To enable silent push notifications in your app, complete the following:

Step 1: Modify your .plist, or on the Capabilities tab, under Background Modes, enable the Remote notifications background mode.

Add background mode remote notifications in Xcode

Step 2: Call the Swrve SDK from the following method in your AppDelegate.m:



Note: When a silent notification is delivered to the user’s device, iOS gives your app up to 30 seconds to run. Ensure you initiate any download operations needed to fetch new data within that 30 second window.

Step 3: Add code to your app to remove the badge number notification, for example, in the applicationWillEnterForeground callback:

Processing custom payloads

If you want to capture any custom key/value pairs passed with the push notification, capture the notification data in your application’s didFinishLaunchingWithOptions and use the delegate methods provided by SwrvePushResponseDelegate.

Note: You must define the delegate class before you initialize Swrve.



The method above enables you to specify any launch parameters that you want to capture and take action on.

Disabling push notification method swizzling

To reduce the number of code changes required to implement push notifications using the Swrve SDK, by default method swizzling is used around the iOS push notification methods.

In some cases, especially where custom handling of push notification methods is required, it is necessary to disable the Swrve SDKs push notification method swizzling. Use the following code if you want to disable method swizzling:



Creating and uploading your iOS certificate

To enable your app to send push notifications to iOS devices, you require a push certificate. A push certificate authorizes an app to receive push notifications and authorizes a service to send push notifications to an app. For more information, see How do I manage iOS push certificates?

Provisioning your app

Each time your app is published for distribution, you must provision it against the push certificate that has been created for the app.

Adding a service extension

To display rich push notifications in your app and track the delivery of those push notifications, iOS uses a notification service app extension. You must add a notification service extension to make use of the following SDK features:

  • Rich media options, including custom response buttons. Rich push notifications are available in iOS SDK versions 4.11 and above.
  • Push notification delivery. As of version 6.4, the Swrve iOS SDK automatically tracks and logs when a push notification is delivered to the device.

This section describes how to add a service extension to your app. It also covers how to add an app group to handle tracking delivery and influenced users of rich push notifications and how to process notification responses, if required.

For examples of how to integrate rich push notifications in the Swrve iOS SDK, see the Swrve iOS SDK samples folder on GitHub.

Creating a notification service extension

Step 1: In Xcode, add a service extension to your project:

  1. Select New > Target to add a new target to your project.
  2. In the iOS > Application Extension section, select the Notification Service Extension target and then select Next.
  3. Specify the name and other details for your app extension and then select Finish.
    Note: When naming the service extension, it’s important that the start of the Bundle identifier for the service extension is the same the main app’s. For example:
    Main App: YourCompany.YourApp
    Service extension: YourCompany.YourApp.YourAppServiceExtension
  4. When prompted, select Activate to activate the extension.

Step 2: Since service extensions were only introduced in iOS 10, change the Deployment Target of the service extension to 10.0 to maximize compatibility with iOS 10+ versions of the app. (The Deployment Target of the app can be lower than iOS 10.)

Step 3: In CocoaPods, add a new target block with the same name as your service extension and only include the latest SwrveSDKCommon pod (that is, from the same version of the SDK that your main app uses). For example:

Do not include the SwrveSDK pod. It is not required for a service extension and, as certain features in the SwrveSDK pod are not permitted in a service extension, will cause compilation errors.

Step 4: For both the service extension and your main app, on the Signing & Capabilities tab, ensure Push Notifications are enabled:

Xcode capabilities with Push Notifications added

Step 5: Run a pod install.

Step 6: Import Swrve Push and add the following to the service extension NotificationService class:

Objective C


Step 7: For debugging, set the Executable of your service extension target to your main app.

On iOS 10, there is an intermittent issue with notification service extensions where, in some debugging instances, the rich media attachment is not displayed. This is a common issue that has been raised with Apple, but should not affect the production version.

If you are managing provisioning profiles for your app, you must create one for your service extension as well.

Step 8: Start your application and ensure that it’s registered for push notifications.

Step 9: To verify the service extension has been set up correctly, send a rich push notification to your QA device.

If you experience any issues, in your main app check that the service extension is added to the Embedded Binaries (this should be done automatically by Xcode).

Adding an app group to your service extension

Complete the steps in this section to make use of the following SDK features:

  • Influenced metrics for rich notifications and background (silent) updates. Influenced reporting is useful for seeing how many of your users who didn’t interact directly with a push notification later opened the app in a certain window after receiving the notification. Influenced reporting is available in iOS SDK versions 4.10 and above.
  • Push notification delivery. As of Swrve iOS SDK version 6.4, Swrve automatically tracks and logs when a push notification is delivered to the device.

To track delivery of and influence from rich media push notifications or background (silent) updates, the application needs to share stored information with the service extension. An app group enables the service extension to save and load the delivered and influenced data to a shared container that the main app can access on startup.

To add an app group

Step 1: In the Apple Developer portal, create a new App Group. Enter the description and name as group.BundleID.

Step 2: On the portal, go to your app ID for your main app, add the App Group capability and select your new App Group in the checkbox provided.

When you check the Application Services on the portal, App Groups should be enabled.

app groups enabled

Step 3: Repeat the above step for the app extension.

Step 4: If your provisioning profiles are not handled by Xcode, you will need to regenerate them as adding an app groups will make them invalid. For example:

regenerate provisioning profile

Select the profile, select Edit and then select Generate. It is not necessary to make a new provisioning profile, as the status will change to Valid after you select Generate.

Step 5: In Xcode, for both the app and app extension, go to the Capabilities tab, enable App Groups, and select your App Group.

A notification window should appear with the message, “iOS Test App Service Extension Development profile is out of date. Download an updated version from the developer website.” Select Update.

Select the App Group for both targets.

Add App Group to service extension

Step 6: In your SwrveConfig, add the same identifier for your app group to the appGroupIdentifier property:

Step 7: In the service extension, where you call the function handleNotificationContent, include the same appGroupIdentifier.

Step 8: Compile and run the app.

Send a rich push notification to your QA device, do not interact with it but open the app directly and you should see influenced events coming in to your reporting.

Processing notification responses

With the addition of custom buttons to the push campaign workflow, if desired, you can also manage the expected response of notifications for the following scenarios:

  • How the notification is displayed when the app is running in the foreground.
  • How the user engages with the notification.

If you don’t need to do anything with the push notification response, no other steps are needed. Swrve automatically tracks and reports on engagement in the push campaign report. If you want to add any additional work, complete the following:

Step 1: Set the class in which you initialize Swrve to be a SwrvePushResponseDelegate and add the following to the SwrveConfig:

Objective C


This should be done before Swrve is initialized. Otherwise, there’s a chance the delegate will not be attached to our push processing at the time a user engages with a notification or button.

Step 2: Add the SwrvePushResponseDelegate methods to the class you’ve set as the pushResponseDelegate:

  • didReceiveNotificationResponse  – used for processing when the user interacts with the notification. Once this is fired, we’ve already processed the userInfo and events so it’s up to you if you want to include any additional actions. Ensure you call the completionHandler() at the end.



  • willPresentNotification  – used when the app is running in the foreground. Inside the function, you can choose to display an alternative UI or even the push itself if you pass any of the UNNotificationPresentationOptions values into the completionHandler as shown below.



Step 3:  If you are configuring your own notification categories for given instances, we have provided a SwrveConfig property to fill before initializing Swrve. This is notificationCategories for Apple’s iOS 10 Push Notification Framework  (UNNotificationCategory). We recommend adding to SwrveConfig as follows:

Objective C


Requesting other device permissions

Request other device permissions from your users, such as camera, contacts, location, and photo library, with our preconfigured Conversation templates. To enable tracking and device permission requests, you must implement the SwrvePermissionsDelegate delegate and set it in your SwrveConfig object, as the following example for camera permissions demonstrates.



In-app messages and Conversations

Swrve’s in-app messages and Conversations campaigns are available by default and require no additional integration steps. These features enable you to send personalized messages to your app users while they’re using your app. For more information, see Intro to in-app messages and Intro to Conversations.

Conversations are currently not supported on OTT platforms.

To test in-app messages or Conversations in your app, you need to first create the campaign in Swrve. For more information, see Creating in-app messages and Creating Conversations.

If you want to display an in-app message or Conversation as soon as your view is ready, you must trigger the display event when the view controller is in the viewDidAppear state and not in viewDidLoad state.

In-app message and conversation deeplinks

When creating in-app messages and Conversations in Swrve, you can configure message buttons to direct users to perform a custom action when clicked. For example, you might configure a button to direct the app user straight to the app store to provide a rating.

Swrve’s default deeplink behavior for in-app messages and conversations is to treat deeplinks as URLs, so you can use your existing custom URL scheme. If you have not already registered a custom URL scheme, you’ll need to do this before using deeplinks from in-app messages and conversations.

Once the custom URL scheme is set, your app can receive and direct users from outside of the app.

In-app message custom actions

For conversations, deeplinks strings are always handled as URLs. For in-app messages, it is also possible to override this behavior of treating custom actions as URL deeplinks and integrate custom actions to direct users to a sale, website or other target when they click an in-app message. Use the following callback:



For example, to send Swrve events using custom actions, add a customButtonCallback like this:



Dismiss button callback

To be notified of a dismiss button callback action, add the following code:



Overriding in-app message display

Swrve’s iOS SDK displays in-app messages automatically. The messages are implemented as objects of the type UIWindow that are displayed on top of your app’s top-most view. You may need to customize this approach in certain circumstances; for example, if you require full control over the animated segue or fine-grained control over the view hierarchy. If you require this level of control in your app, contact your CSM at and inform them about your particular needs.

To override the default display mechanism, your app must supply a delegate object that implements the SwrveMessageDelegate protocol. You must then assign your delegate to SwrveMessageController.showMessageDelegate. For more information, see the inline documentation in the SwrveMessageController.h header file.

Sending events

The Swrve SDK automatically sends certain events and also enables you to track user behavior by sending custom events. (For a list of default Swrve events, see Segment audience filters, Events.) In turn, you can use app-generated events to trigger in-app messages, while both app- and server-generated events help you define segments and perform in-depth analysis.

Custom events

To send a custom event, include the below example in a method where you want to send an event to Swrve.



Requirements for sending custom events:

  • Do not send the same named event with different case. For example, if you send tutorial.start, then ensure you never send Tutorial.Start.
  • Use a period (.) in your event names to organize their layout in the Swrve dashboard. Each ‘.’ creates a new branch in the Event name column of the Events report, and groups your events so they are easy to locate.
  • Do not send more than 1000 unique named events.
    • Do not add unique identifiers to event names. For example, Tutorial.Start.ServerID-ABDCEFG
    • Do not add timestamps to event names. For example, Tutorial.Start.1454458885
  • Do not use the swrve.* or Swrve.* namespace for your own events. This is reserved for Swrve use only. Custom event names beginning with Swrve. are restricted and cannot be sent.

Event payloads

You can add and send an event payload with every event. This allows for more detailed reporting around events and funnels.

Notes on associated payloads:

  • The associated payload should be a dictionary of key/value pairs; it is restricted to string and integer keys and values.
  • There is a maximum cardinality of 500 key-value pairs for this payload per event. This parameter is optional, but only the first 500 payloads are displayed in the dashboard. The data is still available in raw event logs and for audience filtering.
  • It is not currently possible to use payloads as triggers for push notifications. Use events for these purposes.
  • If you want to use event payloads to target your campaign audiences, you can configure up to 10 custom events with a maximum of 20 payloads per event for audience filtering purposes. For more information, see Targeting your audience by event payloads.



For example, if you want to track when a user starts the tutorial experience, it might make sense to send an event named tutorial.start and add a payload time that captures how much time it took the user to complete the tutorial.



Custom payloads on Swrve Conversation events

It is now possible to add custom payloads to a limited set of Swrve Conversation input events, to a maximum of five payloads. The custom payload is added to the following Swrve internal events (where the event name format is Swrve.Conversations.Conversation-ID.event_name):

  • star-rating – Triggered when a user selects a response in a star rating survey.
  • choice – Triggered when a user selects a choice in a text survey.
  • play – Triggered when a user selects “play”on a video.

Objective C


Custom user properties

The Swrve SDK sends certain user properties by default and also enables you to assign custom properties to update the user’s status. (For a full list of the default user properties, see Assigning user properties.)

For example, you could create a custom user property called premium, and then target non-premium users and premium users in your campaigns.

When configuring custom properties for iOS, you can use a variety of data types (integers, boolean, strings) that the SDK then converts to an integer (for number-based values) or string (in the case of boolean, “true/false”) before sending the data to Swrve. When creating segments or campaign audiences, depending on which data type the property is converted to, you must then select the correct operator (equals for numbers, is for strings) for the property to be properly returned.

Example of group of user properties



Example of single date-typed user property

Use the NSDate object to send a DateTime user property; for example, the current date at the time of a user purchase:



Virtual economy events

To ensure virtual currency events are not ignored by the server, make sure the currency name configured in your app matches exactly the Currency Name you enter in the App Currencies section on the App Settings screen (including case-sensitive). If there is any difference, or if you haven’t added the currency in Swrve, the server will ignore the event and return an error event called Swrve.error.invalid_currency. Additionally, the ignored events are not included in your KPI reports. For more information, see Add your app.

If your app has a virtual economy, send the purchase event when users purchase in-app items with virtual currency.



Send the currency given event when you give users virtual currency. Examples include initial currency balances, retention bonuses and level-complete rewards.



In-app purchase events and validation

If your app has in-app purchases (IAPs), send the IAP event when a user purchases something with real money.

Notify Swrve when an in-app purchase occurs as follows:



Enabling IAP receipt validation

Swrve automatically validates iOS in-app purchases and ignores any events that are considered fraudulent as per Apple guidelines.

To enable validation of IAP receipts against your app:

Step 1: On the Settings menu, select Integration Settings.

Step 2: Under IAP Validation, in the iTunes App Bundle Identifier section, enter your Apple Bundle Id.

Step 3: Select Save.

Although Swrve can validate IAP receipts without this identifier, providing it enables Swrve to verify a receipt against the app itself for greater precision during validation. Swrve checks that the bundle ID included in an in-app purchase receipt corresponds to your bundle ID before calculating your revenue KPIs. This ensures that your revenue figures are as accurate as possible (ignoring pirates and cheaters).

Generally, you enter the Apple bundle ID when configuring the Integration Settings screen as part of the Swrve onboarding process. You can edit the settings on this screen at any time.

To access your bundle ID, access the information property list file (<App>-Info.plist) in your Xcode project.

Verifying IAP receipt validation

Use the following events to monitor the success of IAP receipt validation:

  • swrve.valid_iap – fired if receipt verification is successful and the receipt is valid.
  • swrve.invalid_iap – fired if receipt verification is successful and the receipt is invalid.

Unvalidated IAP

If you want to build revenue reports for your app but don’t have or want the receipt to be validated by our servers, use the function below. This might be required for any purchases in the app that are not made via Apple—this revenue should be validated before this function is called, as any revenue sent by this event is automatically counted in the Swrve dashboard.



Resource A/B testing

Integrating Swrve’s resource A/B testing functionality enables you to use Swrve to test how users respond to changes to the native app content. For more information about resource A/B testing, see Intro to resource A/B testing.

To get the latest version of a resource from Swrve using the Resource Manager, use the following:



If you want to be notified whenever resources change, you can add a callback function as follows:



Testing your integration

After you’ve completed the above, the next step is to test the integration. For more information, see Testing your integration.

Upgrade instructions

If you’re moving from an earlier version of the iOS SDK to the current version, see the iOS SDK upgrade guide for upgrade instructions.

SDK samples

For sample integrations of the Swrve iOS SDK, see the Swrve iOS SDK samples on GitHub.