React-native-firebase: Dynamic links iOS don't work (Random issue)

Created on 16 Apr 2020  ·  19Comments  ·  Source: invertase/react-native-firebase


Issue



Describe your issue here

Our app is based on Dynamic links to log in but some users are not able to get the expected behavior because the dynamic link just opens the browser instead of the app.

It is weird because for most users it works but some cases don't is very random

Project Files






Javascript

Click To Expand

#### `package.json`:

# N/A
#### `firebase.json` for react-native-firebase v6:
# N/A
### iOS
Click To Expand

#### `ios/Podfile`: - [ ] I'm not using Pods - [x] I'm using Pods and my Podfile looks like:

# N/A
#### `AppDelegate.m`:
// N/A


Android

Click To Expand

#### Have you converted to AndroidX? - [ ] my application is an AndroidX application? - [ ] I am using `android/gradle.settings` `jetifier=true` for Android compatibility? - [ ] I am using the NPM package `jetifier` for react-native compatibility? #### `android/build.gradle`:

// N/A
#### `android/app/build.gradle`:
// N/A
#### `android/settings.gradle`:
// N/A
#### `MainApplication.java`:
// N/A
#### `AndroidManifest.xml`:
<!-- N/A -->


Environment

Click To Expand

**`react-native info` output:**

 OUTPUT GOES HERE
- **Platform that you're experiencing the issue on**: - [ ] iOS - [ ] Android - [ ] **iOS** but have not tested behavior on Android - [ ] **Android** but have not tested behavior on iOS - [ ] Both - **`react-native-firebase` version you're using that has this issue:** - `e.g. 5.4.3` - **`Firebase` module(s) you're using that has the issue:** - `e.g. Instance ID` - **Are you using `TypeScript`?** - `Y/N` & `VERSION`




iOS Needs Repro Links Stale

Most helpful comment

Hey @Vitiell0,
We've been facing the same problem for four months. We use v 6.2.0, and we followed instructions from the RN Firebase docs. It works perfectly on Android, and it seems it doesn't work on iOS 13.3.

We send registreation confirmation links via email. They open the app and continue the user registration process. About 25% of links behave as web links - they open a browser, then there is a banner page, and if you click "open" button, it redirects you to a page from link parameter. It seems the app doesn't recognize a universal link as its link.

The problem is we cannot recreate the issue on our test devices. It occurs only on production and, unfortunately, we don't have access to these devices.

We use these parameters in dynamic link apn, ibi, link, ofl.

We still support URL schema links, and there is this snippet in our appDelegate.m. we copy-pasted it from https://reactnavigation.org/docs/4.x/deep-linking#ios , and we followed attached instruction.

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

All 19 comments

Hey @marioacero, can you provide the context to reproduce this error? Otherwise, no one can attempt to debug I'm afraid.

Looks like there is an issue related with iOS 13

We have been experiencing this issue as well for the last few months. @marioacero are you using RN Firebase V5 or V6?

Hey @Vitiell0,
We've been facing the same problem for four months. We use v 6.2.0, and we followed instructions from the RN Firebase docs. It works perfectly on Android, and it seems it doesn't work on iOS 13.3.

We send registreation confirmation links via email. They open the app and continue the user registration process. About 25% of links behave as web links - they open a browser, then there is a banner page, and if you click "open" button, it redirects you to a page from link parameter. It seems the app doesn't recognize a universal link as its link.

The problem is we cannot recreate the issue on our test devices. It occurs only on production and, unfortunately, we don't have access to these devices.

We use these parameters in dynamic link apn, ibi, link, ofl.

We still support URL schema links, and there is this snippet in our appDelegate.m. we copy-pasted it from https://reactnavigation.org/docs/4.x/deep-linking#ios , and we followed attached instruction.

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

About 25% of links behave as web links - they open a browser, then there is a banner page, and if you click "open" button, it redirects you to a page from link parameter. It seems the app doesn't recognize a universal link as its link.

Same here – works in certain cases, fails in others. The Dynamic Links have failed for about 3 of my 8 testers. I've been using "@react-native-firebase/dynamic-links": "^6.3.4".

Duplicate of #3450, where many other lost souls have been gathering since April, too.

I found one case where, after waiting a few days, a newly-generated Dynamic Link started working properly, without rebuilding, reinstalling, or reopening the app. Really don't understand what the cause of failure might be. But the bottom line is that this is far too faulty to use as an authentication method.

Yeah, this is pretty bad. We've had to redesign our entire auth flow due to these problems and as a result we've dropped Dynamic Links from our app.

I just received an App Store rejection due to React Native Firebase Dynamic Links causing the auth flow to fail. See how the reviewer, after clicking the Dynamic Link, wasn't taken into the app and instead ended up on my workaround page (which tries to complete authentication via an Action Extension instead) then decided to reject the app on the spot:

image

The previous build of my app, which uses all the same authentication code, and has an unchanged setup in the Firebase dashboard, was accepted. At that time, for whatever reason, auth worked.

I'm feeling pretty helpless after two months of trying earnestly to get authentication working in React Native Firebase. This library just cannot be depended on.

@Appkidd what workaround did you use? Are you still authenticating via Firebase?

"The library" is many things - this has nothing to do with firestore for instance, and it's in the library.
The problem I think is dynamic links in general are useful to short-circuit user discovery etc but no they are not reliable - there are simply too many moving parts in the system to rely on it for something like auth in my opinion

On the other hand, the auth library works great, with all the auth providers I've tried (google, facebook, apple, email, SMS) working very well with the only irritation being that SMS is also a bit unreliable depending on the carrier (to be very specific there is one carrier in Ecuador where I live that never passes the SMS) so you always need a backup solution.

Curious to hear what Appkidd says as well I don't think he got it all working but he had good info

Hi @mikehardy thanks for the response.

On the other hand, the auth library works great, with all the auth providers I've tried (google, facebook, apple, email, SMS) working very well

Out of those authentication flows, which ones rely on neither Dynamic Links nor Universal Links?

I've implemented SMS-based authentication, but also want to provide email-based authentication for privacy purposes (and as a backup method). Is there any way to achieve email-based authentication through Firebase without the flow depending on Dynamic Links or Universal Links?

EDIT: I should add that I was specifically using passwordless email login. I don't know whether passworded email login uses Dynamic Links or Universal Links in the flow. Does it still use it for verifying the email?

Email + Password account does not use dynamic links at all, it uses either pre-generated-and-work-pretty-well-but-are-not-pretty firebase auth handlers and email templates in the cloud that mark the account "email verified" at which point you can go on (and if you do an AppState foreground/background hook to check and advance when you re-foreground it's pretty easy for user too in most cases). And you can replace the not-pretty templates with your own handlers to send email and process the click too.

Passwordless for email I don't know.

I do know that as soon as I implemented facebook and google auth (and the requisite apple sign in that they make you do, once you do any social), EVERY PERSON USES FACEBOOK AND GOOGLE. In all caps because I was thinking, most maybe. But it's like 99%

None of the ones I listed use dynamic links at all actually, to be very clear. I'm only just now implementing links but I'm just doing it to reduce friction of user-to-user discovery where I will have a few backup methods available as well

@mikehardy Thanks so much, these other options give me hope.

I don’t know whether the failure of Dynamic Links used in auth flows to open apps is due to RNFB, the FB library, FB auth backend, FB Dynamic Links backend, or iOS Universal Links themselves; but knowing that there’s an option for email-based auth that doesn’t depend upon Dynamic/Universal Links is a relief. I do wish the Google docs would warn of it being potentially unreliable, though.

Passwordful email auth is less slick but seems far less likely to fail.

I’ll leave out social auth for now, but it’s great to know that they don’t involve Dynamic Links. Do they still involve Universal Links, though?

Hey @shirakaba - sorry for the slow reply. We've used Firebase Auth with traditional email/pass for the time being with the hopes of upgrading to passwordless auth when it becomes more stable. I've read tonnes of pages on the Apple Developer forums of people complaining about Universal Links in iOS 13. I'm unsure as to exactly where the root of the problems lay but it's clear that this isn't just a problem experienced by us Firebase users.

@Appkidd thanks for mentioning! So it is ultimately a Universal Links failure, then.

I have a one-on-one WWDC session with a Safari/WebKit developer tonight and I’ll see if they can comment on the situation at all. Hopefully it doesn’t slip my mind.

@shirakaba That's awesome - I'd be keen to hear how you get on with that.

@Appkidd I have ten other questions to ask during the 25 minutes, so may not be able to do it justice, but will certainly try to touch upon it. Worth booking a one-to-one yourself too if you’d like to have a more detailed discussion on the matter. It’s quite easy to get an appointment and there are more appointments available this week, not just with that team but a variety of other ones who may even be more relevant.

@Appkidd I ran out of time at the end of the session, and the Universal Links expert wasn't around for my one-to-one, but I did manage to briefly mention it and they did say that it was news to them that Universal Links were failing and that we should bring it up on the forums or book another lab session this week to talk about it.

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.

Closing this issue after a prolonged period of inactivity. If this is still present in the latest release, please feel free to create a new issue with up-to-date information.

Was this page helpful?
0 / 5 - 0 ratings