Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improper Swizzling of application:openURL:options: #2205

Open
5 tasks done
waltflanagan opened this issue May 8, 2023 · 11 comments
Open
5 tasks done

Improper Swizzling of application:openURL:options: #2205

waltflanagan opened this issue May 8, 2023 · 11 comments

Comments

@waltflanagan
Copy link

Checklist before submitting a bug report

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
Copy link

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

@shomin1983
Copy link

We're experiencing the same issue

@dodatw
Copy link

dodatw commented Nov 15, 2023

Same Here!

@olejnjak
Copy link

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

@olejnjak
Copy link

Here is minimal example for my case FBSample.zip

@Cedrick84
Copy link

Cedrick84 commented Aug 4, 2024

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
Copy link

Same issue here

@jscalo
Copy link

jscalo commented Sep 16, 2024

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
Copy link

ptsochantaris commented Sep 18, 2024

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
Copy link

It seems to be solved in the newest version 17.3.0.

@jscalo
Copy link

jscalo commented Oct 15, 2024

Confirmed issue is fixed in 17.3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants