firebase-ios-sdk: handleUniversalLink always returns false when app launch after installation

Step 1: Describe your environment

  • Xcode version: 12.1
  • Firebase SDK version: 7.0-spm-beta
  • Installation method: Swift Package Manager
  • Firebase Component: DynamicLinks

Step 2: Describe the problem

handleUniversalLink always returns false when app launch after installation

Steps to reproduce:

  1. Create dynamic link in firebase console. Link should open appstore if application not installed
  2. Remove application from device
  3. Open dynamic link in browser, check Save my place in the app. A link will be copied to continue to this page.
  4. Install app from Xcode in debug mode
  5. func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) called with url from firebase

Expected behavior:

  • DynamicLinks.dynamicLinks().handleUniversalLink(url) returns true

Real behavior:

  • DynamicLinks.dynamicLinks().handleUniversalLink(url) always returns false

When Im opening installed app from this link all works as expected.

Diagnostic output:

---- Firebase Dynamic Links diagnostic output start ----
Firebase Dynamic Links framework version 7.0.0
System information: OS iOS, OS version 13.4, model iPhone
Current date 2020-11-17 12:06:01 +0000
Device locale ru-CA (raw ru_CA), timezone America/Edmonton
	Specified custom URL scheme is my.bundle.id and Info.plist contains such scheme in CFBundleURLTypes key.
	AppID Prefix: Z8M*****M8, Team ID:  Z8M*****M8, AppId Prefix equal to Team ID: YES
performDiagnostic completed successfully! No errors found.
---- Firebase Dynamic Links diagnostic output end ----

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 23 (8 by maintainers)

Most upvoted comments

@eldhosembabu

Would be great if you can clone this PR and check whether its working for you and let me know so that I can push in the changes for next release.

Will do. Going to report back when I’ve done so.

@eldhosembabu I think what @brunsman meant is that when the link is URL encoded as in his case and in my case, the regex does not accidentally match the slashes in &link=https:// since we instead have &link=https%3A%2F%2F. So I think you guys are on the same page regarding that 😃