Improper Swizzling of `application:openURL:options:`

[waltflanagan]

Checklist before submitting a bug report

• [X] I've updated to the latest released version of the SDK
• [X] I've searched for existing GitHub issues
• [X] I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group
• [X] I've read the Code of Conduct
• [X] This issue is not security related and can safely be disclosed publicly on GitHub

Xcode version

14.3

Facebook iOS SDK version

16.1.0

Dependency Manager

SPM

SDK Framework

Core

Goals

After updating to SDK 16.* we found that application:openURL:options: was always returning NO/false when called. This is due to swizzling implemented here. The return value is not passed through this implementation.

We would like to have callers of application:openURL:options: receive the correct return value of the method.

Expected results

If the implementation of application:openURL:options: returns YES then the callers of the method should receive YES

Actual results

Callers of application:openURL:options: always receive NO.

Steps to reproduce

Implement a UIApplicationDelegate class and hard core application:openURL:options: to return YES/true.

Link against FBAEMKit and enable it such that it swizzles application:openURL:options:

Code samples & details

No response

[squarefrog]

We're experiencing this issue too - it has broken our deep link implementation, so we're going to have to downgrade.

[shomin1983]

We're experiencing the same issue

[dodatw]

Same Here!

[olejnjak]

It is the same story with application(_:continue:restorationHandler:) -> Bool and Facebook SDK 16.3.1

[olejnjak]

Here is minimal example for my case FBSample.zip

[Cedrick84]

This issue still exists in 17.0.2 Attached is the AppDelegate illustrating the issue AppDelegate.swift.zip

The problem is that FBSDKFeatureAppAemAutoSetUpProxy is disabled when querying the gatekeeper, therefore FBSDKAEMManager.enableAutoSetup is initialized with proxyEnabled set to false.

This leads to the method being swizzled from bool to void, which is interpreted as false.

It was introduced in v16.1.1 in this commit.

[alex-taffe]

Same issue here

[jscalo]

Same issue here. Can we get the priority raised? I would think this impacts the Xcode 16 deployment of almost every FB-linked app.

[ptsochantaris]

One workaround is to pass the openURL OpenURLAction value from the UI (if you're using SwiftUI) down to your URL handler and use that to open a URL. That does not go through the UIKit route so the FB hack doesn't break it.

For example:

    @Environment(\.openURL) private var openURL

    ...

    static func openURL(_ url: URL, via action: OpenURLAction) async -> Bool {
        let accepted = await withCheckedContinuation { continuation in
            action(url) {
                continuation.resume(returning: $0)
            }
        }

        if accepted {
            print("Opening external URL: \(url)")
        } else {
            print("Warning: Failed to open external URL: \(url)")
        }
        return accepted
    }

I hope this is of help to anyone struggling with the same issue, and hope that FB creates a fix for this soon.

[RobertDresler]

It seems to be solved in the newest version 17.3.0.

[jscalo]

Confirmed issue is fixed in 17.3.0.