Deeplinking implementation causes other deeplinks to be unhandled (iOS/Android).

[ciawalsh]

Report

Plugin Version

6.0.50

On what Platform are you having the issue?

Android & iOS.

What did you do?

Install the plugin using the steps provided within the documentation.

What did you expect to happen?

Appsflyer to run correctly.

What happened instead?

It does, however, the methods provided now override any incoming deeplink - So for instance logging in through Facebook, a deeplink back to the app with the login information is no longer handled correctly.

Please provide any other relevant information.

I have this within my iOS AppDelegate.m

// Add deep linking support
- (BOOL)application:(UIApplication *)app
   openURL:(NSURL *)url
   options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options
{
  if ([[FBSDKApplicationDelegate sharedInstance] application:app openURL:url options:options]) {
    return YES;
  }
  if ([RCTLinkingManager application:app openURL:url options:options]) {
    return YES;
  }
  // Appsflyer Deeplinking Support - 'redundant conditional'
  if ([AppsFlyerLib shared]) {
    [[AppsFlyerLib shared] handleOpenUrl:url options:options];
    return YES;
  }
  return NO;
}

I also have this within the MainActivity.java file for Android...

  // Appsflyer Android Deeplink support
  @Override
  public void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    // setIntent(intent); <--- breaking line
  }

It seems for iOS you can only have one method for handling deeplinks, but within that method, it needs to return a boolean for whichever package can handle the incoming link - Usually, these checks are done with conditionals which return booleans themselves, however with AppsFlyer's implementation, it doesn't. I've wrapped it like the above, however, i'm pretty sure it's picked up every time as the library itself is there, so that conditional seems pretty redundant. Assuming this is synchronous code, I'm hoping it being last will only run if the other two methods aren't valid for the specific deeplink for appsflyer - it's currently very hit and miss.

For Android, the setIntent() is causing FB & Google logins to fail (when the native apps are installed that can handle login - which ultimately means passing deeplinks around to go between apps) - Having a look at answers like this which shows that the implementation of onNewIntent, will let the new intent that comes in, be handled above anything that was running previously - which clearly isn't how we need to be handling the login, it needs to be running on the previous intent.

Looking at one of your contributor's answers previously, it seems that this line is needed to help override intent on cold startups.

I'm hoping that we can find a way to keep handling your deeplinks without it, however, causing side-effects with other deeplinks that come in such as FB/Google logins through their native apps. Perhaps (for android as an example) if your 'intent' object has a specific type or data we can look for, we can setIntent dependant on whether it's an appsflyer deeplink or not?

[amit-kremer93]

Hi @ciawalsh, in order for you to get the best answers about native sdk questions you can contact our support team support@appsflyer.com

[lucasroca]

Hi @ciawalsh and @amit-kremer93. I have this exact same use case on both platforms. Did you manage to solve it?

[professorkolik]

Same here, I wouldn't say this is completely native sdk topic Same issue in unity plugin => https://github.com/AppsFlyerSDK/appsflyer-unity-plugin/issues/47

[filippobarcellos]

@ciawalsh How did you manage to solve it? I have the same problem.

[ciawalsh]

Very late to respond, but they ended up removing AppsFlyer as it caused more problems then it solved. Especially as they relied on Social OAuth.

Sorry @filippobarcellos - The above was on a version of RN that was over 2 years old (pre 66), as were the OAuth logins, so I'm sure they've all had time to get their ducks in a row in the meantime. Perhaps reach out to @amit-kremer93 or support@appsflyer.com if that issue really does still persist.