feat: add Swift AppDelegate support for expo

[saseungmin]

Add Swift AppDelegate Support for expo

🎯 Overview

This PR extends the plugin to support Swift AppDelegate files for AppsFlyer integration, addressing compatibility with Expo SDK 53+ which now defaults to generating Swift AppDelegate files instead of Objective-C.

📱 Background

• Expo SDK 53+ now defaults to generating AppDelegate.swift instead of AppDelegate.m
• Previous plugin versions only supported Objective-C AppDelegate files
• This caused manual integration requirements for all new Expo projects using the default template
• Related Issues:
  • [🔥 iOS Build] I can't build on react-native new arch Swift project #622
  • [Expo] Plugin doesn't support Swift AppDelegate #620

✨ Changes

• ✅ Swift AppDelegate Support: Automatic modification of AppDelegate.swift files
• ✅ Bridging Header Management: Automatic #import <RNAppsFlyer.h> addition to bridging headers
• ✅ Backward Compatibility: Existing Objective-C AppDelegate support unchanged

Swift AppDelegate Integration

// AppDelegate.swift
// Automatically adds to openURL method:
AppsFlyerAttribution.shared().handleOpen(url, options: options)

// Automatically adds to continueUserActivity method:
AppsFlyerAttribution.shared().continue(userActivity, restorationHandler: nil)

// {name}-Bridging-Header.h
#import <RNAppsFlyer.h>

Why restorationHandler: nil?

AppsFlyer doesn't actually use the restorationHandler internally. Evidence from AppsFlyer's own implementation:

// From AppsFlyerAttribution.m - receiveBridgeReadyNotification method
// https://github.com/AppsFlyerSDK/appsflyer-react-native-plugin/blob/bb5271cd5da6fa5c7e6d4bbfecfa77f531ea3372/ios/AppsFlyerAttribution.m#L77
- (void)receiveBridgeReadyNotification:(NSNotification *)notification {
    // ... other code ...
    if([self userActivity]) {
        [[AppsFlyerLib shared] continueUserActivity:[self userActivity] restorationHandler:nil];
        //                                                                              ^^^^ nil!
        [self setUserActivity:nil];
    }
}

• AppsFlyer itself passes nil for delayed universal link processing
• Actual UI restoration is handled by React Native's RCTLinkingManager, not AppsFlyer

🚨 Error Handling

• Swift AppDelegate pattern mismatch:

• Missing Bridging Header:

🧪 Test

• Expo SDK 53, react-native v0.79.2 project with default Swift AppDelegate
• Fix deep link navigation issue when app is in background on Android

[arekkubaczkowski]

Really appreciate for this one. Just one comment, some time ago when I tried to do it manually in the expo app I was having issues with deeplinks at specific circumstances. Can you please make sure that all possible deeplink paths work properly yet?

AFAIR it was during the cold start where deeplinks weren't catched by SDK.

[saseungmin]

Really appreciate for this one. Just one comment, some time ago when I tried to do it manually in the expo app I was having issues with deeplinks at specific circumstances. Can you please make sure that all possible deeplink paths work properly yet?
AFAIR it was during the cold start where deeplinks weren't catched by SDK.

@arekkubaczkowski

Thanks for the comment
I tested the cold start scenario you mentioned and it worked fine without any issues. All the deeplinks I'm using are functioning properly as well.

Here are the test cases I covered:

• IOS (physical device via TestFlight, simulator)
  Cold start (completely closed app): ✅
  Background state: ✅

• Android (emulator)
  Cold start (completely closed app): ✅
  Background state: ✅

However, since I'm using the free version, I was only able to test with OneLink.

[saseungmin]

If deep links are not working properly when the app is running in the background on Android, please add the following code to android/app/src/main/java/com/{appname}/app/MainActivity.kt:

import android.content.Intent

override fun onNewIntent(intent: Intent) {
  super.onNewIntent(intent)
  setIntent(intent)
}

Note: This code differs slightly from the original PR. The original used override fun onNewIntent(intent: Intent?) with a nullable Intent parameter, but this caused compilation errors, so I've updated it to use a non-null Intent parameter.

[arekkubaczkowski]

If deep links are not working properly when the app is running in the background on Android, please add the following code to android/app/src/main/java/com/{appname}/app/MainActivity.kt:

import android.content.Intent

override fun onNewIntent(intent: Intent) {
  super.onNewIntent(intent)
  setIntent(intent)
}

Note: This code differs slightly from the original PR. The original used override fun onNewIntent(intent: Intent?) with a nullable Intent parameter, but this caused compilation errors, so I've updated it to use a non-null Intent parameter.

I believe it's necessary to add the compatibility for Expo as well. The plugin shouldn't be complex tho

[arekkubaczkowski]

@saseungmin

#372 (comment)

[jensellfors]

What's the progress on this, need this to upgrade our app... Not sure if any engineers from AppsFlyer are here?

[arekkubaczkowski]

What's the progress on this, need this to upgrade our app... Not sure if any engineers from AppsFlyer are here?

I guess not, you can create a local patch using patch-package for now

[huylocit14054]

This is blocking our app from upgrading to Expo 53. Hope that this issue gets resolved soon.

[itsramiel]

I saw your comment that restorationHandler is not being used internally. I do think it is better to work with the external Api in case the internal one ever starts using it. You could work around the error you were getting with:

      AppsFlyerAttribution.shared().continue(userActivity) { array in
        restorationHandler(array as? [UIUserActivityRestoring])
      }

[saseungmin]

@itsramiel

Thanks for the suggestion! I think keeping restorationHandler: nil is cleaner for now.

1. Current state: Since AppsFlyer doesn't use restorationHandler internally, we'd be passing unused data through an unnecessary closure.

2. Type safety concerns: The suggested array as? [UIUserActivityRestoring] casting assumes AppsFlyer will always provide the correct type, but we don't have guarantees about their internal implementation.

3. Future updates: If AppsFlyer adds functionality that uses restorationHandler, we'll need to update the library anyway, so we can implement it properly at that point.

I think it's better to keep the code simple and explicit rather than adding complexity for future scenarios. When the feature is actually added, we can implement it then.

I'll follow the AppsFlyer maintainer's opinion on this matter for future implementation.
Thanks!

[mapledan]

This is blocking our app from upgrading to Expo 53. Hope that this issue gets resolved soon.

We’re encountering the same issue as well. Hopefully, it can be resolved soon.

[arapocket]

Any news on this?

[arapocket]

I've reached out to AppsFlyer support and didn't get any definitive update, just that their product team would look into it.

[takuro-kira]

same, at react native without framework. react-native v0.80.1
hope update document from 2years ago.
https://github.com/AppsFlyerSDK/appsflyer-react-native-plugin/blob/master/Docs/RN_DeepLinkIntegrate.md

[arapocket]

AppsFlyer got back to me and said that the fix will be prioritized for early August.