Firebase Dynamic Link limitations and expected behaviour on iOS

[Jan Klausa]

Hello!

I've been trying to integrate Firebase Dynamic Links for the better part of the week now and I'm at the point where I think I'm reaching the limits of the service.

While all of the use cases we care about seem to be supported on Android, I've been hitting my head pretty severely against the wall while trying to get it to work on iOS.

For some background on our setup (mostly focused on iOS, since we're not really having big troubles on Android side):  

We have two apps, one for iOS and one for Android.

We integrate Firebase on the iOS side by adding `pod 'Firebase/DynamicLinks', '~> 3.2'` to our `Podfile`.

We've added the required entitlements to our App ID, reprovisioned everything. The `apple-app-site-association` file on Firebase/Google's server contains the expected values.

We're making a call to `-[FIRDynamicLinks handleUniversalLink:completion:]` in `application:continueUserActivity:restorationHandler`.

We're making a call inside `application:openURL:options:` to `application:openURL:sourceApplication:annotation`, as per recommendation in the docs.

We're making a call inside `application:openURL:sourceApplication:annotation:annotation` to `[FIRDynamicLinks dynamicLinkFromCustomSchemeURL]`.

We're providing `ibi` and `ius` parameters in our Firebase Dynamic Links (as per https://firebase.google.com/docs/dynamic-links/ios).

...that about covers it.

So, here's what works:

On iOS 9 devices, with the app already installed on the device, tapping on the links in an app that doesn't have it's own in-app browser (Slack, Notes), opens the app and the iOS Universal Link callback (`application:continueUserActivity:restorationHandler`) gets called. We get the "real" URL from there and handle it fine.

On iOS 9 device, with the app already installed on the device, tapping on the links in Safari (or SFVC, for that matter) triggers the same behaviour.

On iOS 8 device, with the app already installed on the device, entering the URL into Safari, opens the app, the `application:openURL:sourceApplication:annotation` gets called, we call `dynamicLinkFromCustomSchemeURL:` on Firebase and handle it.

On iOS 8 devices, with the app already installed on the device, tapping on the links in an app that doesn't have it's own in-app browser, triggers the same behaviour. 

On iOS 8 device, with the app already installed on the device, tapping on the links in Safari (or SFVC, for that matter) triggers the same behaviour.

On both iOS 9 and iOS 8 devices, with the app not installed on the device, accessing the link with any of the previously mentioned methods, _*on the first launch of the app after installing it*_, the `application:openURL:sourceApplication:annotation` gets called asynchronously some time after the launch.

Now that we got the good out of the way, time for the bad and the ugly.

Here's what _doesn't_ work:

On iOS 9 device, with the app installed on the device, entering the URL into Safari doesn't open the app. Instead, it redirects to the URL specified by `link` parameter. From my understanding, this is the expected behaviour of _iOS Universal Links_, but I'm not exactly clear of what's the expected behaviour of _Firebase Dynamic Links_ here. 

On iOS 9 device, with the app installed on the device, long-pressing the URL in apps like Notes and choosing "Open in Safari", instead of "Open in Clue", the URL specified by `link` parameter is opened in Safari and it doesn't open the app.

On iOS 9 device, with the app installed on the device, opening the URL in an app that has it's own web browser implementation (think Facebook Messenger), the app isn't opened and the website specified by the `link` parameter is displayed.

In all of the cases listed above, not opening the app is unfortunate, though from my (limited) understanding, in some cases unavoidable.  

However, even though the app isn't opened automatically, _when the user manually opens the app_, I'd expect to get the same callback I do when the app is first launched after a "fresh install". 

This is clearly within capabilities of the framework, since such machinery is used to "fingerprint" a user for the fresh-after-install callback, and could be used for this case.

This is crucial to our usage of the framework. Is this something that's _not a feature that Firebase is interested in providing_, a bug, an oversight, an implementation error on our side? The docs are rather lacking in explaining what exactly _are_ all the supported use cases for Dynamic Links.

(FWIW: most of my expectation of how this "should work" is based on how Branch is working - which, given that Firebase Dynamic Links are obviously a direct competitor to, doesn't seem entirely off-base)

Mostly, I'm at loss if I'm doing something that wasn't envisioned as use case for Dynamic Links or if I'm hitting a bug. 

I'd really love some clarification and/or help with debugging this issue. 

As a final note: there are other people on the web confused about the same issue, and there doesn't seem to be an official answer, see https://github.com/firebase/quickstart-ios/issues/17 (and similar others).

Thanks in advance for any help!

[Todd Kerpelman]

Hi, all!

> On iOS 9 device, with the app installed on the device, entering the URL into Safari doesn't open the app. Instead, it redirects to the URL specified by `link` parameter. From my understanding, this is the expected behaviour of _iOS Universal Links_, but I'm not exactly clear of what's the expected behaviour of _Firebase Dynamic Links_ here. 

That's the expected behavior of Dynamic Links as well, since it's based on Universal Links in iOS9.

> On iOS 9 device, with the app installed on the device, long-pressing the URL in apps like Notes and choosing "Open in Safari", instead of "Open in Clue", the URL specified by `link` parameter is opened in Safari and it doesn't open the app.

That's also expected behavior. If a user explicitly asks to open the link in Safari, we don't open the app and, instead, go to the link parameter in Safari.

> On iOS 9 device, with the app installed on the device, opening the URL in an app that has it's own web browser implementation (think Facebook Messenger), the app isn't opened and the website specified by the `link` parameter is displayed.

That's the current expected behavior as well, I believe. If an app decides to open the URL inside its own webview, Universal Links doesn't have a chance to take over. I believe we're looking into ways around this, but I'm not sure we have a better solution at this time.

> However, even though the app isn't opened automatically, _when the user manually opens the app_, I'd expect to get the same callback I do when the app is first launched after a "fresh install". 

An app will only do one "check for pending dynamic links" call per lifetime, so this is probably expected behavior, unless you're uninstalling and reinstalling the app every time. I'll also need to check if this behavior is also true if the user ends up at the "link" parameter instead of the App Store. We might only set a pending dynamic link if the user goes to the app store. I'll update this thread when I know more.

--T

[Todd Kerpelman]

Just to follow-up on my earlier post -- we do set pending deep link information whether or not the user goes to the app store or the contents of your `link` parameter. But, as I stated before, the Dynamic Links library only does one "check for pending dynamic links" call per lifetime of your app. So if you want to see this behavior while testing, you'll need to uninstall and reinstall your app.

--T