Troubleshooting - iOS SDK - Airbridge Help Center

Issue

When running an app built with the Airbridge iOS SDK in a Swift 6 environment, the app crashes when the closures passed to functions such as handleDeeplink and handleDeferredDeeplink are invoked.Affected functions

Airbridge.handleDeeplink
Airbridge.handleDeferredDeeplink
Airbridge.createTrackingLink
Airbridge.click
Airbridge.impression
AirbridgeOptionBuilder.setOnAttributionReceived

Cause

In Swift 5.x and earlier, the compiler only issued warnings even when there was a risk of a data race caused by multiple threads accessing the same memory at the same time. In Swift 6, any data or closure that may move to and run on another thread or actor-isolated context must be proven safe to transfer across threads. Otherwise, the compiler may raise a compile-time error, or a runtime crash may occur when building with backward compatibility.

Solution

When using Airbridge SDK functions that receive closures as parameters, explicitly add the @Sendable annotation before the closure parameter variable to tell the compiler that the data can be safely transferred across threads.

Deep Link Install or Deep Link Open not occurring, resulting in standard Install or Open

Problem

To trigger a Deep Link Install or Deep Link Open, the trackDeeplink method must be called before the didBecomeActive state in the iOS Lifecycle. If trackDeeplink is called after didBecomeActive, it will be recorded as an Organic Install or Open.

Cause

The Deep Link Install or Deep Link Open events are not generated; instead, standard Install or Open events occur.

Solution

Please ensure that trackDeeplink is called before didBecomeActive.By setting the setLogLevel to Debug in the AirbridgeOptionBuilder, you can verify the following logs in sequential order:

Following app state detected: state=didDeeplink
Following app state detected: state=didBecomeActive

CocoaPods cannot find version 4.7.0

During the deployment of version 4.7.1, an issue occurred where version 4.7.0 was accidentally removed. The 4.7.0 version has since been redistributed to CocoaPods.If CocoaPods is unable to find the version, or if you encounter a checksum error with the installed Pods, please follow the steps below.

pod cache clean --all
pod repo remove trunk
pod setup 

pod install --repo-update

The domain of saved passwords appears as airbridge.io or abr.ge

Problem

Users may see the domain of passwords stored with the Password AutoFill feature as airbridge.io or abr.ge.

Cause

After setting up deep links for the Airbridge SDK, if you utilize the Password AutoFill feature, the domain is saved as the applinks domain of the Airbridge deep link, which is airbridge.io or abr.ge.

Solution

The problem can be solved by setting up the webcredentials domain used in the Password AutoFill.

Prepare the domain that will store the password.
Host the JSON below at https://YOUR_DOMAIN/.well-known/apple-app-site-association with Content-Type: application/json. Your prepared domain should be entered instead of YOUR_DOMAIN.

You can find the App ID Prefix and Bundle ID in the [Identifiers]>[YOUR_APP] menu of the Apple Developer Portal.

{
    "webcredentials": {
        "apps": ["YOUR_APP_ID_PREFIX.YOUR_BUNDLE_ID"]
    }
}

Navigate to [YOUR_PROJECT]>[Signing & Capabilities] in Xcode.
Click + Capability to add Associated Domains. Enter webcredentials:YOUR_DOMAIN in Associated Domains.

Upload Symbol Failed on Xcode

Problem

Upon uploading the app to the App Store, Xcode displays a warning message that a dSYM for the Airbridge framework was not included.

Cause

The Airbridge iOS SDK does not support dSYM.

Solution

The dSYM will be supported in the coming update. You may ignore this warning.

​Issue

​Cause

​Solution

Problem

Cause

Solution

​Problem

​Cause

​Solution

​Problem

​Cause

​Solution

Issue

Cause

Solution

Problem

Cause

Solution

Problem

Cause

Solution