firebase-ios-sdk: 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:

https://forums.developer.apple.com/thread/123554

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

Service: applinks
App ID: TeamID.BundleID
App Version: 1.0.0.0
Domain: domain.page.link User Approval: unspecified
Site/Fmwk Approval: unspecified
Flags:
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 Flags: 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:

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 10
  • Comments: 60 (14 by maintainers)

Most upvoted comments

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).

@morganchen12 app opens as expected on iOS 12.4.5

Rebooting the phone fixed it.

On Mar 28, 2020, at 11:46 AM, Alejandro Taboada notifications@github.com wrote:

Hey! The fact is that after some hours/days begins working without making any change. That means that the json content is fine, otherwise wouldn’t work.

Ios 13 on new devices handles the domain info in a different way. Pleas check that device logs and will see that the domain wasnt verified and the next validation date is an invalid date in the past. Meaning that os will check in the future when the os consider it. Thats why it begins working afterwards. Is not a redirection problem, not a header. Please check your response time (full connection + response ) to see if its good enough

El El sáb, 28 mar. 2020 a la(s) 09:42, ghus86 notifications@github.com escribió:

@c0diq https://github.com/c0diq I have found this page from apple they also talk in app identifier not teamID and that

https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app

A validation may fail and the association will be denied if: The JSON file is invalid or doesn’t contain the application identifier.

they also mention that starting iOS12 it should include

Include the following JSON with your domain for the webcredentials service.

@morganchen12 https://github.com/morganchen12 @paulb777 https://github.com/paulb777 is it possible that the AASA needs to be updated ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-605442522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6NVDO3OW5IGC7TSAURMSDRJXWEDANCNFSM4KWFTD3A .

– Alejandro Taboada (ataboada@gmail.com) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Same problem here. Used to work. Not anymore since updating to iOS 13.4. One thing I noticed is that the documentation states to enter the App ID (prefix) in the Settings but the only setting I see is Team ID. Our Team ID is totally different than the App Prefix in some cases. Yet Firebase is using the TeamID to build the App ID (prefix + bundle ID) when generating the AASA file so I have to put the AppID prefix in the Team ID field instead of the real Team ID. Please update your docs. https://firebase.google.com/docs/dynamic-links/ios/receive

Ensure that your app's App Store ID and your App ID prefix is specified in your app's settings. To view and edit your app's settings, go to your Firebase project's Settings page and select your iOS app.

You can confirm that your Firebase project is properly configured to use Dynamic Links in your iOS app by opening the following URL:

https://your_dynamic_links_domain/apple-app-site-association

If your app is connected, the apple-app-site-association file contains a reference to your app's App ID prefix and bundle ID. For example:

{"applinks":{"apps":[],"details":[{"appID":"1234567890.com.example.ios","paths":["/*"]}]}}

If the details field is empty, double-check that you specified your App ID prefix. Note that your App ID prefix may not be the same as your Team ID.

My app AASA is properly configured as when I tap my universal links, the app launches. It has to do with using firebase AASA and redirect not working.

I include the same aasa file on azure web and other 2 domains, using similar headers, and it worked only on azure. The only difference I found is the response time.

It only happens with certain devices.

On Wed, Mar 25, 2020 at 7:51 AM ghus86 notifications@github.com wrote:

@aletabu https://github.com/aletabu thanks for the feeback if I understand correctly our suggestion is to put the AASA to an azure server ?

I am using firebase inside unity and this strange it works well in iOS 13.3 and 13.4 for an Iphone SE but when clients try on iphone 11 or X it doesnt open the app

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-603772970, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6NVDP5B3XV4WPWEK6KQZDRJHO4BANCNFSM4KWFTD3A .

– Alejandro Taboada (ataboada@gmail.com)