157240254: Dynamic Links reopens (Universal links) not working consistently on iOS13

Step 1: Describe your environment

  • Xcode version: 11.3.1
  • Firebase SDK version: 6.15.0
  • Firebase Component: Dynamic Links
  • Component version: 6.15.0
  • Installation method: CocoaPods

Step 2: Describe the problem

Steps to reproduce:

Dynamic Links are not working consistently on iOS13. I would say approximately 8-10%% of our users are having trouble – they get redirected to the continue URL instead of getting taken to the app.

For troubled devices, the AASA file is not downloaded properly when the app is installed, as is detailed in the following topic:


When running sysdiagnose and exporting, the app data looks like this:

Service: applinks
App ID: TeamID.BundleID
App Version:
Domain: domain.page.link
User Approval: unspecified
Site/Fmwk Approval: unspecified
Next Check: 0001-01-01 03:26:23 +0000

Patterns field is missing and Site/FMwk Approval is unspecified.

On devices where the AASA file is properly downloaded, it looks like this:

Service: applinks
App ID: TeamID.BundleID
App Version: 1
Domain: domain.page.link
Patterns: {“/”:”/_/“,”exclude”:true}, {“/”:”/“}
User Approval: unspecified
Site/Fmwk Approval: approved
Last Checked: 2020-01-22 18:30:50 +0000
Next Check: 2020-01-27 18:20:51 +0000

Users on the aforementioned apple developer topic seem to have resolved the problem by serving the AASA over http/1.1 rather than http/2.

Can you please advise how best to proceed with this?

We are using the firebase supplied domain.page.link domain so have no control over how the AASA file is served.

We really need a fix for this as lots of users are complaining on app store connect.

Relevant Code:

1 possible answer(s) on “157240254: Dynamic Links reopens (Universal links) not working consistently on iOS13

  1. Hey all! Thanks for looking into this.
    We’ve had an issue related to dynamic links which may or may not be the same as this thread.
    Dynamic links shared through the share sheet, in iMessage, won’t redirect when clicked. Looking at the URL that is sent, it’s not the deep link and it’s not the long URL either, it’s the preview URL. When I curl the long URL with no User-Agent, I get a 302 redirect, which leads me to the small preview HTML with the meta tags. When I curl the long URL with the iOS Safari User-Agent, I get the correct 200 response with the HTML/JS to do the App Store redirect.

    My guess here is that iMessage is caching the URL after the redirect that occurs because they don’t set the same User-Agent as safari. I’m guessing also that you’re doing this check for the User-Agent to send a small payload for preview, which is definitely a good idea but it seems like it’s breaking all iOS 13 iMessage sharing. I think as a fix you could see what the User-Agent is that iMessage sets when it makes its preview HTTP GET request, and return the full page instead of just the preview. They’ll cache just that and everyone’s links will work again.

    Just fyi, Apple recommends against checking User-Agent on the backend: https://developer.apple.com/library/archive/technotes/tn2444/_index.html (see Consistent metadata for all user agents)

    In the meantime, our fix is to share the url.absoluteString instead of the url directly:

    let activityViewController = UIActivityViewController(activityItems: [url.absoluteString], applicationActivities: nil)
    activityViewController.popoverPresentationController?.sourceView = self.view
    self.present(activityViewController, animated: true, completion: nil)

    This seems to work in all apps we care about, as they do the link preview request on text as well as URLs (so does iMessage actually).