iOS SDK integration guide for marketers

Robin Daysy

Last update: August 02, 2021 13:25

Recommended for

Advertisers
Developers

At a glance: Integrate AppsFlyer SDK into iOS apps to measure installs, in-app events, media sources, and more.

1. Overview

The SDK provides app installation and event recording functionality. You can record installs, updates, sessions, and in-app events. In-app events include, for example, in-app purchases or leveling up in a game. Recording these events can help you evaluate ROI and user quality.

The SDK integration requires that the marketer and the developer work together. This guide describes the decisions and actions that the marketer must perform during the integration and links to the relevant developer documentation.

This article describes the SDK integration process for V6+. Additional documentation includes the following:

Updating to iOS SDK V6. Note that iOS SDK V5.4.4 is fully operational with iOS 14. However, we recommend adopting SDK V6.X to ensure compatibility with future iOS releases.
Release notes
Deprecated SDK versions

1.1 SDK compatibility

The AppsFlyer iOS SDK is compatible with the following platforms:

iOS 9+ (iPhone, iPod, iPad)
tvOS 9+ (Apple TV)
Complies with Apple IPv6 DNS64/NAT64 networks

The SDK supports multiple attribution methods. The attribution methods that are used depend on the following:

The iOS version installed on the user's device
The iOS SDK version installed in the app

Attribution methods supported	iOS version	iOS SDK support	Notes
Probabilistic modeling	8 – 14.4	5.0.0+
Probabilistic modeling	14.5+	6.0.3+	Probabilistic modeling is limited to the context of owned media, cross-promotion, and consented web-to-app flows.
ID matching	8 - 13	5.0.0+	Users can opt out using Limit Ad Tracking (LAT).
ID matching	14.5+	6.0.3+	App Tracking Transparency (ATT) is enforced. For more information, see configure the iOS SDK to support ATT.
SKAdNetwork	11.3 - 13	6.0.3+	SKAdNetwork Solution is limited to install attribution in accordance with the SKAdNetwork specification, meaning there is no conversion value.
SKAdNetwork	14+	6.0.3+	SKAdNetwork Solution is always available at the iOS and SDK levels irrespective of the ATT setting. The marketer enables in the AppsFlyer dashboard.

Starting from SDK V6.0.8, Apple App Clips attribution is available. You can also read our blog post about Apple App Clips.

1.2 SDK integration

The SDK integration includes the following:

Tab

Tasks

After completion

SDK Integration
[Mandatory]

Retrieve the AppsFlyer dev key and send the link to the developer.
Send the developer instructions for installing the SDK in your app and integrating the SDK.
Review the App Tracking Transparency (ATT) guidelines and send the developer instructions for ATT implementation. Decide on the wording for the ATT consent dialog box, and provide the text to your developer.
Configure SKAdNetwork measurement in the AppsFlyer platform.
Work with the developer to test the SDK integration.

Basic attribution reporting can begin for your app. You can start to view real-time LTV user-acquisition (UA) performance in the dashboard.

Core APIs
[Recommended]

Determine the in-app events that you want to measure, and send the event names and event parameters to the developer along with these instructions.
Determine the deep linking methods to use, and send the developer the implementation instructions.
Learn about the available methods for accessing attribution data.

View in-app events and revenue on your dashboard and understand actions performed by users after conversion.
Use deep linking to direct new users to personalized content, or run retargeting campaigns and serve existing users customized content.

Additional APIs

Work with your developer to implement optional APIs such as:

Measure uninstalls, referrals, user engagements with push notifications, and manage user privacy scenarios.

The SDK reference documentation for developers is here.

2. Integrating the SDK

AppsFlyer uses the dev key to uniquely identify your account. The dev key is required because it enables the SDK to securely send and retrieve data that belongs to your account.

To retrieve your dev key:

In AppsFlyer, go to Configuration > App Settings.
Copy your dev key, and send it to your developer.
Provide your developer with these instructions to install and integrate the SDK.

3. iOS 14 Support

This section includes important information about support for iOS 14+ devices, and guidelines to follow when working with the developer to integrate the SDK into your app.

3.1 Configuring App Tracking Transparency (ATT) support

Background

Starting with iOS 14.5, IDFA collection requires user consent. Practically, it means IDFA access is governed by the App Tracking Transparency (ATT) framework. On iOS 14+ devices, SDK uses the ATT framework to obtain access to the device IDFA.

For an introduction to ATT, see ATT principles.

When attribution occurs using IDFA, it's important IDFA is sent on the first launch. For this reason, the SDK provides the waitForATTUserAuthorization utility.

waitForATTUserAuthorization overview

Important!

Do not call waitForATTUserAuthorization if you don't intend to invoke the ATT prompt.

waitForATTUserAuthorization enables you to configure how long should the SDK defer sending data to the AppsFlyer servers, and wait for ATT status.

When a user launches the app, ATT status is notDetermined. During the waitForATTUserAuthorization timeout:

The SDK queues the launch event and consecutive in-app events in-memory, similar to the way in which offline events are recorded.
If the user consents to the ATT prompt (IDFA collection):
- The SDK adds the IDFA to cached events.
- The SDK starts and sends cached events with IDFA (without waiting for the timeout to end).
If the user declines the ATT prompt:
- The SDK starts and sends cached events without IDFA (without waiting for the timeout to end).
If the timeout ends and ATT status remains notDetermined:
- The SDK starts and sends cached events without IDFA.

Considerations

Calling requestTrackingAuthorization without setting waitForATTUserAuthorization will result in launches and events being sent without IDFA for iOS 14+ devices.
If the user moves the app to the background during the timeout:
- The timer pauses until the app returns to the foreground.
- Events are cached in-memory.
If the user shuts down the app/the app is killed during the timeout:
- The timer is restarted on the next app launch.
- Cached events are lost.

3.2 Customizing ATT consent dialog

You can choose to customize the ATT prompt. A message that clearly states the purpose of the request might help increase the opt-in rates for users.

Note the following when creating your message:

Use wording that best explains to your users why the app is asking for user consent.
Inform users about how their data will be used. To learn more about user privacy and data use, click here.

Once your message is complete, provide your developer with the text and these instructions.

To view some external examples of ATT prompts, click here.

3.3 Support for SKAdNetwork attribution

Note

To fully support SKAdNetwork attribution, upgrade to iOS SDK V6.2.3+.

SKAdNetwork is a class used by iOS that validates advertiser-driven app installations. The app install validation process involves the source app and the advertised app.

A source app is an app that participates in ad campaigns by displaying ads signed by an ad network. Configuring your app to display ads is not within the scope of the AppsFlyer SDK. To configure, follow the Apple instructions.

For the advertised app (the app with the AppsFlyer SDK), the AppsFlyer SKAdNetwork Solution uses SKAdNetwork to provide the attribution postback while AppsFlyer collects, translates, and aggregates the data while maintaining user privacy. When the app is launched for the first time, the AppsFlyer platform uses the configuration set by the marketer to instruct the SDK how to set the SKAdNetwork conversion value.

To use the SKAdNetwork Solution:

The marketer needs to configure SKAdNetwork measurement in AppsFlyer. The developer does not have to perform any tasks.
AppsFlyer SDK automatically calls the necessary SKAdNetwork APIs.
Make sure to disable SKAdNetwork calls in other SDKs when relying on AppsFlyer for SKAdNetwork attribution.
There is no other action or registration process required by either the developer or the marketer in the App Store.

To disable SKAdNetwork attribution, instruct your developer to disable it in the SDK.

4. Test installs

Once the SDK integration is complete, you can go to the AppsFlyer dashboard, and from the SDK Integration Tests page, test organic and non-organic installs, in-app events, and deep linking. This ensures that installs and in-app events are recorded and attributed correctly.

If you need your developer to test the SDK integration, add the developer as a team member in your account, so they can access the dashboard.

For testing scenarios and instructions, see SDK integration testing.

5. Recording in-app events

In-app events (IAE) provide insight into what is happening in your app. Recording in-app events helps you to measure KPIs such as ROI (Return on Investment) and LTV (Lifetime Value). We recommend taking the time to define the events that you want to record.

Once you determine the in-app events that you want to measure, send the event names and event parameters to your developer, and include a link to these instructions.

To learn more about in-app events, see our Rich in-app events guide.

Record revenue

You can send revenue with any in-app event. Make sure you use the af_revenue parameter to include revenue. It is the only event parameter that AppsFlyer counts as real revenue on the raw data and dashboard. For more details click here.

For developer instructions, see logging revenue.

Validate in-app purchases

The AppsFlyer SDK provides server verification for in-app purchases. Validating an in-app purchase automatically sends an in-app purchase event to AppsFlyer. Sending this event yourself creates double duplicate event reporting.

Industry verticals

If your app belongs to a vertical such as travel, gaming, or eCommerce, see our list of recommended in-app events per vertical.

6. Deep linking with OneLink

OneLink is the AppsFlyer solution for multi-platform device detection, redirection, and deep linking.

6.1 Device detection and redirection

For users without your app installed, OneLink detects the device type and redirects them to the correct destination (for example, Google Play, Apple App Store, third-party app store, or web page). This is based on your OneLink template settings. Learn more

Note: Device detection and redirection do not require the AppsFlyer SDK. However, the SDK is required for deep linking.

6.2 Deep linking

For users with your app installed, OneLink opens the app. In addition to opening the app, you can also deep link users to a specific activity or page within the app. This requires your developer to implement Unified Deep Linking (UDL).

Note:

UDL requires SDK V6.1+.
Customers already using OneLink for deep linking may be using the legacy method, instead of UDL.

See our guide on setting up deep linking with OneLink.

6.3 Deferred deep linking

For users without your app installed, OneLink detects the device type and redirects them to the correct destination (for example, Google Play, Apple App Store, third-party app store, or web page). Once the user launches the app, you can use deferred deep linking to redirect them to a specific activity or page within the app.

This requires your developer to implement Unified Deep Linking (UDL).

Note:

UDL requires SDK V6.1+.
Customers already using OneLink for deferred deep linking might be using the legacy method, instead of UDL.

See our guide on deferred deep linking to learn more.

6.4 Configure push notification deep link resolution

AppsFlyer supports the measurement of push notification campaigns from all vendors and can also support developers who use Google Cloud Messaging or Apple push notification services directly. The conversions, defined as app opens originating from push notification messages, display in the Retargeting dashboard.

You can use OneLink to measure user re-engagement via push notifications. See our guide on measuring push notification re-engagement campaigns.

7. Accessing attribution and deep linking data

The following table describes the available methods for retrieving attribution and deep linking data:

Method	Who is involved?	Return results	Retrieval method	Attribution data	Deep linking data	Availability
Push API	Marketer Back-end developer	Up to 60 seconds	Backend	Y	N	Premium
Get conversion data (GCD)	Marketer Mobile developer For developer documentation, click here.	Up to 5 seconds	SDK	Y	Y	All accounts
Unified Deep Linking (UDL)	Marketer Mobile developer For developer documentation, click here.	Up to 1 second	SDK	N	Y	All accounts
Pull API	Marketer Back-end developer	Periodic (not real-time). You can schedule to download a raw-data report.	Backend	Y	Y	Premium for raw-data reports

Note the following for iOS 14.5+ non-consenting users:

When using UDL for paid and owned media, deep linking data is available.
When using GCD for paid media, the data is limited and does not include attribution and deep linking details.

Tip

We recommend the following:

Use Push API when retrieving attribution data and sending it to your servers for further processing. This method waits for the data to become available, and therefore is highly accurate and close to real-time. GCD returns data in real-time, but sometimes might be inaccurate when final attribution decisions are determined after more than 5 seconds.
Use Pull API to periodically (for example, daily) supplement real-time attribution data, and to compensate for any communication errors that might occur.

The following sections include instructions for both the marketer and the developer.

8. Attribution

Measure uninstalls

AppsFlyer enables you to measure the uninstalls rate of users coming from different sources. Uninstall measurement can help you to analyze and optimize your campaigns according to this significant KPI.

To learn how to set up uninstall measurement, read here.

Setting an "SDK started" handler

If you want to receive a confirmation that the SDK started successfully and notified AppsFlyer servers, implement the startWithCompletionHandler handler. You can then apply logic to handle the success or failure of the SDK launch.

Implementation example

[[AppsFlyerLib shared] startWithCompletionHandler:^(NSDictionary<NSString *,id> *dictionary, NSError *error) {
        if (error) {
            NSLog(@"%@", error);
            return;
        }
        if (dictionary) {
            NSLog(@"%@", dictionary);
            return;
        }
    }];

 AppsFlyerLib.shared()?.start(completionHandler: { (dictionnary, error) in
            if (error != nil){
                print(error ?? "")
                return
            } else {
                print(dictionnary ?? "")
                return
            }
        })

In the event that an error occurs during the request listener, an error code and string description are provided, as indicated in the table that follows.

Error code	String description
10	"Event timeout. Check 'minTimeBetweenSessions' param"
11	"Skipping event because 'isStopTracking' enabled"
40	Network error: Error description comes from Android
41	"No dev key"
50	"Status code failure" + actual response code from the server

Set additional custom data

The setAdditionalData API allows you to add custom data to events sent from the SDK. Typically it is used to integrate on the SDK level with several external partner platforms, including Segment, Adobe, and Airship.

setAdditionalData code example:

NSDictionary* customDataMap = [[NSDictionary alloc] initWithObjectsAndKeys:@"value_of_param_1", @"custom_param_1", nil];
[[AppsFlyerLib shared] setAdditionalData:customDataMap];

let customDataMap: [AnyHashable: Any] = [
  "custom_param_1" : "value_of_param_1"
]
AppsFlyerLib.shared().customData = customDataMap

Attribute app sessions initiated from owned websites (domains)

App owners using Universal Links for deep linking (without OneLink), and have a domain associated with their app can attribute sessions initiated via this domain using the appendParametersToDeepLinkingURL method.

For example, a user searches Google and clicks on your domain, www.example.com:

If the user doesn’t have the app installed, they are directed to the website (www.example.com).
If the user has the app installed on their device, they are deep linked into the app associated with www.example.com. The session is attributed to the media source (pid parameter) specified in appendParametersToDeepLinkingURL.

See the iOS SDK reference for additional information.

Note: Smart Banners help app owners convert website visitors to app users.

9. Sessions

Custom time between sessions

By default, at least 5 seconds must pass between two app launches to count as two separate sessions (more about counting sessions).

Use the following API to set the minimum time between sessions:

[AppsFlyerLib shared].minTimeBetweenSessions = <your_custom_time_in_seconds>;

AppsFlyerLib.shared().minTimeBetweenSessions = <your_custom_time_in_seconds>

Setting a high value to the custom time between launches may badly impact APIs relying on session data, such as deep linking.

Background sessions for utility apps

Unavailable in iOS.

10. Owned media

Resolve wrapped deep link URLs

Some 3rd party services such as email service providers wrap links in emails with their own click recording domains. Some even allow you to set your own click recording domains. If OneLink is wrapped in such domains, it might limit its functionality.

To overcome this issue you can use the setResolveDeepLinkURLs API. Use this API to get the OneLink from click domains that launch the app. Make sure to call this API before SDK initialization.

For example, you have three click domains that redirect to your OneLink which is https://mysubdomain.onelink.me/abCD. Use this API to get the OneLink that your click domains redirect to. This API method receives a list of domains that the SDK resolves.

[AppsFlyerLib shared].resolveDeepLinkURLs = @[@"example.com",@"click.example.com"];

AppsFlyerLib.shared().resolveDeepLinkURLs = ["example.com", "click.example.com"]

The code above allows you to use your click domain while preserving OneLink functionality. The click domains are responsible for launching the app. The API, in turn, gets the OneLink from these click domains, and then you can use the data from this OneLink to deep-link and customize user content.

Record push notifications

With AppsFlyer, you can record push notifications as part of retargeting campaigns.

To enable this feature, call the handlePushNotificationData method inside AppDelegate.m.

-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
[[AppsFlyerLib shared] handlePushNotification:userInfo];
}

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    AppsFlyerLib.shared().handlePushNotification(userInfo)
}

For more information on push notification measurement, read here.

User invite attribution

Allowing your existing users to invite their friends and contacts as new users to your app, can be a key growth factor for your app. With AppsFlyer, you can attribute and record installs that originate from user invites within your app.

For details, see the User Invite Attribution article.

Cross-promotion attribution

Note! Cross-promotion by IDFV requires SDK 6.0.2+. IDFV is collected automatically and no further action is required by the developer.

Cross-promoting apps can be a major growth factor in driving additional installs for your apps. AppsFlyer enables you to attribute and record installs originating from a cross-promotion campaign of one of your apps from within the current app the user has.

For details, see the Cross-Promotion Attribution article, here.

11. User identifiers

Get AppsFlyer ID

An AppsFlyer unique ID is created for every new install of an app. You can use this ID for various purposes:

Send server-to-server in-app events.
Match it with user records in your backend systems.
Map entries when merging data from pull and push API.

Use the following API to obtain the unique ID:

NSString *appsflyerId = [AppsFlyerLib shared].getAppsFlyerUID;

let appsflyerId = AppsFlyerLib.shared().getAppsFlyerUID()

Set Customer User ID

Setting your own Customer User ID in AppsFlyer enables you to cross-reference your unique ID with the AppsFlyer unique ID and other IDs. This ID is available in AppsFlyer raw data CSV reports. You can also use it in postback APIs for cross-referencing with your internal IDs.

To set your Customer User ID:

[AppsFlyerLib shared].customerUserID = @"my user id";

AppsFlyerLib.shared().customerUserID = "my user id"

In iOS, the Customer User ID needs to be set with every app launch. We recommend setting the Customer User ID early in the app flow, as it is only associated with events reported after its setup:

If setCustomerUserId is called before calling start, the Customer User ID appears in the raw data reports for installs and for events.
If it is set after, the Customer User ID is only associated with events that are recorded after setting the Customer User ID.

Getting Customer User ID

To avoid setting the Customer User ID value again beyond the first launch, and to reduce calls to your server to get the customer user ID, you can check if its value is empty or not by using:

NSString *customerUserID = [AppsFlyerLib shared].customerUserID;

let customerUserID = AppsFlyerLib.shared().customerUserID

For more information about the Customer User ID, click here.

Delay SDK init for customerUserID

You can delay the SDK Initialization until the Customer User ID is set. This is useful if its important for you that install and event data contain your customer user ID.

Implement the following code:

- (void)applicationDidBecomeActive:(UIApplication *)application {
    NSString *customUserId = [[NSUserDefaults standardUserDefaults] stringForKey:@"customerUserId"]; // Your custom logic of retrieving CUID
    if (customUserId != nil && ![customUserId  isEqual: @""]) {
        [AppsFlyerLib shared].customerUserID = customUserId; // Set CUID in AppsFlyer SDK for this session
        [[AppsFlyerLib shared] start]; // Start
    }
}

func applicationDidBecomeActive(_ application: UIApplication) {
        let customUserId = UserDefaults.standard.string(forKey: "customUserId")  //  your logic to retrieve CUID
        if(customUserId != nil && customUserId != ""){
            AppsFlyerLib.shared().customerUserID = customUserId // Set CUID in AppsFlyer SDK for this session
            AppsFlyerLib.shared().start() // Start
        }
    }

To learn more about delaying the SDK initialization until the Customer User ID is available, go here.

Warning

Use this API only in cases where it is appropriate for your business logic. Using this API increases the chance for discrepancies and might make the app more exposed to fraud.

12. User privacy

Delay initializing the SDK

You may want to delay initializing the SDK and sending data until the user gives consent (for example, GDPR or COPPA consent).

Note: This is unrelated to ATT introduced in iOS 14.

To delay initializing the SDK:

Prevent the session from being sent on background-foreground transition. In a sendLaunch() method (that is called on every applicationDidBecomeActive (as per section 3.3), wrap call to start with a condition check. For example:
```
-(void)sendLaunch:(UIApplication *)application {
    if (consent_given) { // check the condition
        [[AppsFlyerLib shared] start]; // Start
    }
}
```
Send the session as soon as the reason for delaying is no longer relevant (right after condition changes). Call start when you are ready to send the first session data. For example:
```
...
consent_given = YES; // change the condition
[[AppsFlyerLib shared] start]; // Start
...
```

Opt-out

In some extreme cases, you might want to shut down all SDK data logging due to legal and privacy compliance. This can be achieved with the isStopped property. Once this property is set to true, the SDK stops functioning and no longer communicates with AppsFlyer servers.

There are several different scenarios for user opt-out. We highly recommend following the exact instructions for the scenario that is relevant for your app.

Warning

Use the isStopped API only in cases where you want to fully ignore this user from any and all recording. Using this API SEVERELY impacts your attribution, data collection and deep linking mechanism.

[AppsFlyerLib shared].isStopped = true;

AppsFlyerLib.shared().isStopped = true

In any event, the SDK can be reactivated by calling the same API, by passing false.

Important!

Do not call start if isStopped is set to true

To start logging data again, set isStopped to false.

Anonymize user data

AppsFlyer provides you with a way to anonymize specific user identifiers in AppsFlyer analytics. This complies with the latest privacy requirements and with Facebook data and privacy policies. Its default value is false, meaning anonymization isn't performed by default.

Use this API during the SDK Initialization to explicitly anonymize a user install, events and sessions:

[AppsFlyer shared].anonymizeUser = YES;

AppsFlyerLib.shared().anonymizeUser = true

Logging data can be restarted by setting anonymizeUser to false.

Warning

Anonymizing users impacts your attribution information.
Use this option in cases where you are legally restricted from collecting user information.

Strict mode SDK

Use the strict mode SDK to completely remove IDFA collection functionality and AdSupport framework dependencies (for example, when developing apps for kids).

Note: IDFV remains available.

In your Podfile, replace the AppsFlyerLib dependency with:

pod 'AppsFlyerFramework/Strict','6.2.3'

Note: If you use strict mode SDK and call disableAdvertisingIdentifier, you receive a compilation error.

Disabling ad frameworks

To disable the AdSupport and iAd frameworks, the SDK provides the following setters:

disableCollectASA = true. Learn more
disableAdvertisingIdentifier = true. Learn more

To disable ad frameworks:

[AppsFlyerLib shared].disableCollectASA = YES
[AppsFlyerLib shared].disableAdvertisingIdentifier = YES;

AppsFlyerLib.shared().disableCollectASA = true
AppsFlyerLib.shared().disableAdvertisingIdentifier = true

Exclude partners from getting data

In some cases, advertisers may want to stop sharing user-level data with ad networks/partners for specific users. Reasons for this include:

Privacy policies such as CCPA or GDPR
User opt-out mechanisms
Competition with some partners (ad networks, 3rd parties)

AppsFlyer provides two API methods to stop sharing data with some or all partners:

setSharingFilter: Used by advertisers to prevent sharing data with some (one or more) networks/integrated partners.
setSharingFilterForAllPartners: Used by advertisers to prevent sharing data with all networks/integrated partners.

These filtering methods are supported starting in SDK V5.4.1.

The filtering method must be called every time the SDK is initialized and affects the whole session. If it takes time to determine whether you need to set the sharing filters, then delay the SDK initialization.

When the method is activated before the first start call:

Users from SRNs are attributed as Organic, and their data is not shared with integrated partners.
Users from click ad networks (non-SRNs) are attributed correctly in AppsFlyer, but not shared with the ad networks via postbacks, APIs, raw data reports, or by any other method.

Currently, uninstall data can't be filtered using these methods. However, you can stop sending Uninstall events to partners using their setup pages in AppsFlyer.

For a complete list of API methods, click here.

Prev Tab:

Next Tab:

Was this article helpful?

Yes No

Comments

11 comments

KBBot
September 12, 2019 12:42

Hi everyone!

We want to update you that a new AppsFlyer iOS SDK has been released - version 4.10.3.

This version supports iOS 13 updates, specifically push token retrieval for Uninstall Measurement.
The new version also includes bugs fixes and improvements.

We recommend that you update your app to use version 4.10.3.

Thank you!

0

Comment actions Permalink
KBBot
November 12, 2019 12:53

Hi everyone!

We want to update you that a new AppsFlyer iOS SDK has been released - version 5.0.0.

The new version introduces changes to method names and SDK functionality.

We recommend that you update your app to use version 5.0.0. If you update to version 5.0.0, pay attention to changes in method names and conversion data format.

For more information, see the following link:
https://support.appsflyer.com/hc/en-us/articles/360003090618

0

Comment actions Permalink
KBBot
December 24, 2019 09:01

Hi everyone!

We want to update you that a new AppsFlyer iOS SDK has been released - version 5.1.0.

The new version improves Objective-C - Swift interoperability.

When our SDK guarantees that a certain value is not null, we return non-optional value. Otherwise, we return an optional so you need to unwrap it manually. If you migrated from older versions of the SDK and used to have unwrapping “?” character in any code that references the SDK, you will get compile-time error now unless you remove “?” as the returned type is no longer optional.

We recommend that you update your app to use version 5.1.0. If you update to this version, make sure you adapt your code accordingly.

For more information on optional and unwrapping in swift, see the following link:
https://docs.swift.org/swift-book/LanguageGuide/OptionalChaining.html

0

Comment actions Permalink
Ziv Bass Specktor
March 11, 2020 10:20

Hi there!

AppsFlyer iOS SDK version 5.2.0 has been released.
Why should you update to it?

Besides maintenance and bug fixes the new version introduces the following features :
* Allow setting advanced deferred deep linking for Facebook users
* Allow generating branded links when using User Invite feature
* Extended security, logging, and debugging capabilities

If you use these features or haven't updated the SDK in a while, we recommend doing so.

0

Comment actions Permalink
Eli Wrightman
May 05, 2020 10:30

Hi everyone!

AppsFlyer iOS SDK version 5.3.0 has been released! This version includes general bugs fixes and improvements, plus the following additional features:
* Direct deep linking attribution data can be accessed at any time
* Additional parameters are available for cross-promotion impressions
* Main apps and app extensions get the same AppsFlyer ID, so in-app events are grouped similarly

If you need these features or haven't updated the SDK in a while, we recommend doing so.

Thanks!

0

Comment actions Permalink
Eli Wrightman
July 07, 2020 12:49

Hi everyone!

AppsFlyer iOS SDK version 5.4.1 has been released! This version includes general bug fixes and improvements, plus the following additional features:
* setSharingFilter API that allows advertisers to control sharing data with integrated partners/networks.
* onAppOpenAttribution method - aligned the response of iOS Universal Links with the rest of the use cases.

If you need these features or haven't updated the SDK in a while, this is a great time to do so :)

0

Comment actions Permalink
Gray Goldstein
March 08, 2021 06:47

Hi everyone! If you implement SKAdNetwork measurement you must adopt SDK V6.2.3 as prior versions contain a bug the impacts the setting of SKAdNetwork conversion value.

0

Comment actions Permalink
KBBot
March 15, 2021 11:59

Hi everyone!

We've released SDK V6.2.4, which fixes a bug related to SKAdNetwork in Revenue mode and in-app events.
If you implement SKAdNetwork measurement and use Revenue mode, you need to upgrade your SDK to V6.2.4.

For more details, see the iOS SDK release notes:
https://support.appsflyer.com/hc/en-us/articles/115001224823

Thank you!

0

Comment actions Permalink
Daniel Bram
April 28, 2021 13:24

Hi everyone!

We've released iOS SDK V6.2.6.
For more details, see the release notes:
https://support.appsflyer.com/hc/en-us/articles/115001224823

0

Comment actions Permalink
Daniel Bram
May 13, 2021 18:00

Hi everyone!

We've released iOS SDK V6.3.0!
The highlight for this release is Apple Silicon (M1 chipset) support.

For more details, see the release notes:
https://support.appsflyer.com/hc/en-us/articles/115001224823

0

Comment actions Permalink
Daniel Bram
June 17, 2021 19:50

Hi everyone!

Recently we’ve released two iOS SDK updates: V6.3.1 and V6.3.2.
For more details, see the release notes:
https://support.appsflyer.com/hc/en-us/articles/115001224823

0

Comment actions Permalink

Please sign in to leave a comment.

Articles in this section

Page contents:

Recent searches

Don't show me again

Premium feature This AppsFlyer premium feature is available for advanced account plans or as an add-on.

Please contact your AppsFlyer CSM or write to hello@appsflyer.com for more details.

Copy direct link Link copied!

iOS SDK integration guide for marketers

1. Overview

1.1 SDK compatibility

1.2 SDK integration

2. Integrating the SDK

3. iOS 14 Support

3.1 Configuring App Tracking Transparency (ATT) support

Background

waitForATTUserAuthorization overview

Important!

3.2 Customizing ATT consent dialog

3.3 Support for SKAdNetwork attribution

Note

4. Test installs

5. Recording in-app events

Record revenue

Validate in-app purchases

Industry verticals

6. Deep linking with OneLink

6.1 Device detection and redirection

6.2 Deep linking

6.3 Deferred deep linking

6.4 Configure push notification deep link resolution

7. Accessing attribution and deep linking data

Tip

8. Attribution

Measure uninstalls

Setting an "SDK started" handler

Set additional custom data

Attribute app sessions initiated from owned websites (domains)

9. Sessions

Custom time between sessions

Background sessions for utility apps

10. Owned media

Resolve wrapped deep link URLs

Record push notifications

User invite attribution

Cross-promotion attribution

11. User identifiers

Get AppsFlyer ID

Set Customer User ID

Warning

12. User privacy

Delay initializing the SDK

Opt-out

Warning

Important!

Anonymize user data

Warning

Strict mode SDK

Disabling ad frameworks

Exclude partners from getting data

Comments

Articles in this section

Related articles

Page contents: