| App display name | Bundle ID (and URL scheme) | Associated domain | Apple Developer Team name |
|---|---|---|---|
| Sundial | com.sundial.app |
applinks:sundial.page.link |
BGI8L3YEF0 |
| Dynamic Link name | URL Prefix | Dynamic Link short URL | Deep Link | iOS app | App Store ID | continueUrl |
|---|---|---|---|---|---|---|
| Signed in | https://sundial.page.link |
https://sundial.page.link/signed_in |
https://sundial.com/app/signed_in.html |
com.sundial.app |
1234567890 |
https://sundial.com/app/signed_in.html |
-
Long Dynamic Link: https://sundial.page.link/?link=https://sundial.com/app/signed_in.html&isi=1234567890&ibi=com.sundial.app
-
Email address verification URL template:
https://sundial.firebaseapp.com/__/auth/action?mode=<action>&oobCode=<code>
This was actually the redirect sequence from a customer whose authentication flow failed, but it looks no different to a successful instance, so I'm thinking that it's an app-level fault rather than a case of Firebase Dynamic Links occasionally vending out faulty Dynamic Links.
The user, whose email was [email protected], received this link in an email when they requested an email for passwordless email login:
Upon clicking that in their email, it first redirected to here:
It then redirected on to the "static page", leaving them stranded:
To determine the form of the link (out of the three potential links in that redirect flow) that actually triggers the app to open, I researched the application:continueUserActivity:restorationHandler: method in RNFBDynamicLinksAppDelegateInterceptor.m. Specifically, this block of code:
[[RNFBRCTEventEmitter shared] sendEventWithName:LINK_RECEIVED_EVENT body:@{
@"url": dynamicLink.url.absoluteString,
@"minimumAppVersion": dynamicLink.minimumAppVersion == nil ? [NSNull null] : dynamicLink.minimumAppVersion,
}];The email that actually gets emitted as an event, dynamicLink.url.absoluteString, into the app is:
This is the second link out of three in the flow.
Firebase auto-generates this .well-known/apple-app-site-association file at https://sundial.page.link/.well-known/apple-app-site-association:
{"applinks":{"apps":[],"details":[{"appID":"BGI8L3YEF0.com.sundial.app","paths":["NOT /_/*","/*"]}]}}Essentially, when iOS apps visit a link with "://sundial.page.link/*", they determine that instead of handling the URL normally, they need to open the Sundial app.
But not, that is, if it matches: /_/*.
So if we make up a link like https://sundial.page.link/fu/bar, and you send that link to a device that has Sundial installed, then if you tap it from within Slack or whatever, it should open your app.
Test plan:
- if you send that same link to a user who is having issues, ask them if it opens the app.
- try send it via email and via some other source (maybe a link to a gist that has it)
- this should help you understand if there is a problem with the querystring payload / rewriting of the urls in the mail
From https://stackoverflow.com/a/45533475/5951226:
Universal Links work great in most cases, however these can easily and, inadvertently, be disabled! If this happens the user will always be redirected to the website URL until they upgrade their app or reset what we call their “Entitlements File” (link).
If a user taps on the ‘airbnb.com’ or ‘abnb.me’ link in the top-right of our app, the OS will direct the user to the website, but it will also permanently direct any future Universal Link to the mobile website for links with that domain!
This effectively breaks the functionality of Apple Universal Links for the user. This isn’t trackable right now and the only way to reset is to long press the URL and click “Open in “Airbnb”” (not intuitive) or to tap the “Open” button on the Apple Universal Links Banner (Phantom Banner) that was described earlier in this document.