[🐛] getInitialLink() returns null if called too soon after launch [workaround possible! see comments]

[janpe]

EDIT: it appears the workaround below is successful #4548 (comment)

Issue

When my iOS app is completely closed and I use a dynamic link to open the app, getInitialLink returns null if I do it too soon. If I wait a bit it will return the link content correctly. I haven't figured out a way to make sure that the method is ready to be called. Currently I am calling it in useEffect and sometimes I get null and sometimes it works as expected, but I can't get it to work reliably without adding a considerable timeout (something like 1000ms) before calling it. So the functionality definitely works so my setup is fine but there just doesn't seem to be a way to reliably know when I can use getInitialLink.

[mikehardy]

This has been noticed before and is an issue.
What is causing it? I'm not exactly sure - this is an area where we could really use the community's help
If there is any way you could reach in to node_modules and instrument it to log out what the code is attempting to do / data structure contents / assumptions etc and drive this to ground it would really help 🙏

[EnettyTech]

Me too, after update to version 10.0.0. Working on 6.4.0.

[mikehardy]

@bachlongkocanh there were by my count 10 dynamic links releases between 6.4.0 and 10.0.0 and your report does not indicate which platform (ios or android, or both?) so is unfortunately not that informative. You also don't indicate which version of the underlying firebase-ios-sdk / firebase-android-sdk you are using. If you could bisect which version of the package and/or underlying SDK you were using to see when it breaks, that would perhaps isolate exactly which commit or version created the change

https://github.com/invertase/react-native-firebase/blob/master/packages/dynamic-links/CHANGELOG.md

[stale]

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

[florinleu]

I'm having almost the same issue on iOS 14: the initialLink is null when running the application in release mode is the app is closed and launched by tapping on the dynamic link.
I tried several versions of the dynamic links library but it's the same: 10.4.1, 7.5.12, 7.0.0.

[florinleu]

Solved it by adding to AppDelegate.m:

#import <RNFBDynamicLinksAppDelegateInterceptor.h>

• (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:app openURL:url options:options];
  }

• (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray<id> * _Nullable))restorationHandler {
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:application continueUserActivity:userActivity restorationHandler:restorationHandler];
  }

[s-aleinik]

Hello :) I'm facing similar issue as well. Here's the description:

Sometimes const link = await firebase.dynamicLinks().getInitialLink(); returns null, when app is launching from a closed state. But not all the time. It happens randomly. It could be 5 nulls, then 3-4 time with data and then nulls again. It happens ONLY in release mode (debug is working perfectly). Both on iOS and Android platforms, both on simulators and real devices.

Versions:

RN: 0.64.0
@react-native-firebase/app: 8.4.2
@react-native-firebase/dynamic-links: 7.5.3

I've also tried to upgrade to latest, but the issue was there as well.

Also I would like to try the comment above, but when I put #import <RNFBDynamicLinksAppDelegateInterceptor.h> to AppDelegate.m the error Could not build module 'RNFBDynamicLinks' appears.

@mikehardy any suggestions?

One more thing I've noticed. Long Dynamic Links always work. Issue happens only for the short

[stale]

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

[mikehardy]

Not stale, has great info, needs time to investigate, thanks for the patience all involved

[danlupascu]

Here's a solution that worked for us. It's just a function that tries to get the dynamic link multiple times with a 500ms interval between the calls. It works pretty well.

import dynamicLinks, { FirebaseDynamicLinksTypes } from '@react-native-firebase/dynamic-links';

const getInitialLink = (
  maxAttempts: number,
): Promise<null | FirebaseDynamicLinksTypes.DynamicLink> => new Promise((resolve) => {
  let link: null | FirebaseDynamicLinksTypes.DynamicLink = null;

  const getLink = async (attempt: number = 1) => {
    try {
      link = await dynamicLinks().getInitialLink();
    } catch (e) {
      // Try again
    }

    if (link) {
      resolve(link);
    } else if (attempt <= maxAttempts) {
      setTimeout(() => {
        getLink(attempt + 1);
      }, 500);
    } else {
      resolve(null);
    }
  };

  getLink();
});


// And somewhere in a `useEffect` hook:
getInitialLink(20).then((link) => {
  if (link) {
    // handleDynamicLink(link);
  }
});

[mtnt]

It is still actual

"react-native": "0.66.1"
"@react-native-firebase/dynamic-links": "14.5.0"

ios: 15.3.1

I`m disagreed with @s-aleinik - a long link also does not work

[thespacemanatee]

This is still happening on iOS release builds and the workaround stated above (delaying retrieval of dynamic links) works for me.

[kierandesmond]

For anyone else here using Expo with React native. The issue we had was on the frontend with getting the initialUrl. Instead use React Native Linking library. like this: https://reactnative.dev/docs/linking - we added the event listener then like in the docs and everything worked a treat!

[austin43]

@kierandesmond Does that solution allow the link to survive the app install process? I could be wrong on this but I'm pretty sure the firebase sdk's have special logic for checking the pasteboard on first run.

[erikmillergalow]

Has anyone encountered varying dynamic link behavior between different Android phone models? Looking around I'm seeing many running into getInitialLink() issues on iOS but I've got something different going on.

On iOS and a Google Pixel 4a getInitialLink() works every time. But when installing on my Samsung Galaxy S21 getInitialLink() returns null every other install consistently(first attempt: null, second attempt: correct link, third attempt: null, etc...). This wouldn't be so much of an issue as real users aren't going to be installing the app repeatedly with our QR codes except that it also consistently returns null on the first install after a restart, which makes me worry that it may fail for every user.

Any guesses on what causes the difference between these two devices? It's possible it's a quirk in my dev environment - I do the majority of my development on the Pixel.

[fowlerp-qlik]

I am also seeing this exact behaviour as @erikmillergalow with getInitialLink on a Samsung S8 Tablet. if I delay my call to getInitialLink() by, say, 10 milliseconds (via setTimeout) then it works every time. Any ideas?

[gawa1019]

Hello.
I had a similar problem on iOS.
(although to be precise, it was getInitialLink() always returning null).

"@react-native-firebase/dynamic-links": "15.2.0"
"react-native": "0.64.3"
iOS: 15.6.1

Finally, I was able to solve it by adding code to AppDelegate.m.

#import <RNFBDynamicLinksAppDelegateInterceptor.h>  // add this line

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  [RNFBDynamicLinksAppDelegateInterceptor sharedInstance]; // add this line
 //-------
 // other code
 //------- 
}

My solution is to call sharedInstance in didFinishLaunchingWithOptions to explicitly set up method swizzing at app startup.
(Not a very smart solution, and sharedInstance will be called several times, but the processing in sharedInstance is guarded by dispatch_once, so there should be no problem if it is called multiple times.)

As far as I have tested, swizzing is enabled by calling the sharedInstance method of the RNFBDynamicLinksAppDelegateInterceptor. Then openURL and continueUserActivity can be processed successfully.

However, in the Release build, openURL is called before sharedInstance, and the URL obtained by getInitialLink() is not saved.
Conversely, in the Debug build, sharedInstance is called before openURL, as intended.

Originally, sharedInstance is called in the init method of RNFBDynamicLinksModule.m.
I think the problem is caused by the different timing of initialization of native modules by react-native due to release, debugging, and other differences.
(I suspect that the difference between Release and Debug that I have experienced is related to downloading the javascript-bundle from the metro server.)

[mikehardy]

The workaround here ☝️ of directly instantiating the interceptor, so that it is swizzled properly and then intercepts links correctly - has received some testing and appears to work well, per feedback in #2660 - a related issue.

apparently the swizzling on the dynamic links interceptor does not happen soon enough some times, so it does not intercept the link, but forcing it to init as the workaround does corrects this so there is no longer a race condition

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[SohelIslamImran]

Same issue

[SohelIslamImran]

1. For Expo people, there is a config plugin that should work for everyone as soon as v16.14.4 is out here (should be shortly)

@mikehardy config plugin not work

[amrit220399]

The workaround provided is causing following issue while doing Build -> Archive

error : undeclared identifier RNFBDynamicLinksAppDelegateInterceptor in AppDelegate.m

I am using react-native-firebase with pod 'Firebase', :modular_headers => true with flipper instead of use_frameworks

[mikehardy]

The workaround provided is causing following issue while doing Build -> Archive

"I am having trouble compiling and building things"

I am using react-native-firebase with pod 'Firebase', :modular_headers => true with flipper instead of use_frameworks

"I am using an unsupported configuration with a workaround that has been explicitly declared problematic when it comes to compiling and building things"

[mishijima]

"@react-native-firebase/dynamic-links": "17.3.1"
"react-native": "0.71.3"
iOS: 16.0

My team and I tried to use the suggested solution for React Native (non-Expo), and it didn't work. The initial link was always null.

What's working for us is to use the suggested solution with issuecomment-762881871 - plus a bit of an update on the restorationHandler because Xcode raises some warnings about a mismatch in the method params.

Our AppDelegate.m looks like the following.

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:app openURL:url options:options];
}

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:
#if defined(__IPHONE_12_0) && (__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_12_0)
(nonnull void (^)(NSArray<id<UIUserActivityRestoring>> *_Nullable))restorationHandler {
#else
    (nonnull void (^)(NSArray *_Nullable))restorationHandler {
#endif  // __IPHONE_12_0
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:application continueUserActivity:userActivity restorationHandler:restorationHandler];
}

@end

[Maxoos]

The workaround provided is causing following issue while doing Build -> Archive

error : undeclared identifier RNFBDynamicLinksAppDelegateInterceptor in AppDelegate.m

I am using react-native-firebase with pod 'Firebase', :modular_headers => true with flipper instead of use_frameworks

Make sure you include #import <RNFBDynamicLinksAppDelegateInterceptor.h> before #if RCT_NEW_ARCH_ENABLED

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[tilted-tm]

Hello, did someone find a solution ? i tried the workaround mentionned but url is still null. Struggling for 3 days now on both ios and android, cannot figure out how to deal with that. If someone has a working example that would be nice :)

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[bhalodiya-vivek]

@tilted-tm @mishijima @mikehardy
Hello all

Firebase Dynamic Link will be shut down soon

https://firebase.google.com/support/dynamic-links-faq?hl=en&authuser=0

[mishijima]

@tilted-tm @mishijima @mikehardy Hello all

Firebase Dynamic Link will be shut down soon

https://firebase.google.com/support/dynamic-links-faq?hl=en&authuser=0

@bhalodiya-vivek, interesting. Thank you very much for this info! 🙇

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[xuanmai-agilityio]

Still got this issue even when I applied a workaround.
I'm using "@react-native-firebase/dynamic-links": "^18.3.0". Any clue would be much appreciated.

[ammarkden]

Whenever I hit the link, it opens Safari not the app. i even opened the link from the notes app and it did not go :(
tho it worked on Android. The problem is in iOS.
Any solutions around?

[mikehardy]

@ammarkden hey there 👋 - a couple things 1- that doesn't sound like the original issue, so it's a thread hijack, 2- dynamic links is deprecated, so I'd be very careful implementing a dynamic-links-based solution right now. As a firebase module it will not be receiving further updates and it will be shut down

That last bit is not great to hear (I have apps that use dynamic links! I'm sad to see it go as I don't want to reengineer the app linking...) but it's important to know. I would use standard react-native (or Expo) linking https://reactnative.dev/docs/linking

[BilalHashmi94]

"@react-native-firebase/dynamic-links": "17.3.1" "react-native": "0.71.3" iOS: 16.0

My team and I tried to use the suggested solution for React Native (non-Expo), and it didn't work. The initial link was always null.

What's working for us is to use the suggested solution with issuecomment-762881871 - plus a bit of an update on the restorationHandler because Xcode raises some warnings about a mismatch in the method params.

Our AppDelegate.m looks like the following.

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:app openURL:url options:options];
}

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:
#if defined(__IPHONE_12_0) && (__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_12_0)
(nonnull void (^)(NSArray<id<UIUserActivityRestoring>> *_Nullable))restorationHandler {
#else
    (nonnull void (^)(NSArray *_Nullable))restorationHandler {
#endif  // __IPHONE_12_0
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:application continueUserActivity:userActivity restorationHandler:restorationHandler];
}

@end

Thanks man I was stuck for days <3