I've also reproduced the issue in the iOS 13.3 simulator.
I've also reproduced the issue in SDK version 6.15.0.

A similar issue was filed in the .NET SDK in 2018 and was resolved by updating the domain to firebasedynamiclinks.googleapis.com, see googleapis/google-api-dotnet-client#1186 for more details.

Thanks for reporting. We will investigate this and report back.

I also have this error when launching the app.

Firebase/DynamicLinks (4.13.0)
Xcode 11.3.1 (11C505)
iOS 13.3.1

Task <04001BC8-E31D-4A9A-BD48-36D5A1FC289C>.<3> finished with error [-1003] Error Domain=NSURLErrorDomain Code=-1003 "Aucun serveur ayant le nom d'hôte précisé n'a été détecté." UserInfo={NSUnderlyingError=0x2805e0540 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorCodeKey=8, _kCFStreamErrorDomainKey=12}}, NSErrorFailingURLStringKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=AIzaSyBEGzjiP42Y_cc6t_ISG1xYLQmoACh7JIA, NSErrorFailingURLKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=AIzaSyBEGzjiP42Y_cc6t_ISG1xYLQmoACh7JIA, _kCFStreamErrorDomainKey=12, _kCFStreamErrorCodeKey=8, NSLocalizedDescription=Aucun serveur ayant le nom d'hôte précisé n'a été détecté.}

edit: wait, now that I posted I can't reproduce. Damn.

Hi, in case its helpful I also see this issue.

2020-03-20 21:53:30.115019-0400 [22075:10757038] Task <5562A0D9-05C7-4593-960F-C09CBE08188C>.<2> finished with error [-1003] Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={NSUnderlyingError=0x600001670810 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorCodeKey=8, _kCFStreamErrorDomainKey=12}}, NSErrorFailingURLStringKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=AIzaSyAS6sGtB1V55M-g8c4Z3rzZaM5DTCnaDZM, NSErrorFailingURLKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=AIzaSyAS6sGtB1V55M-g8c4Z3rzZaM5DTCnaDZM, _kCFStreamErrorDomainKey=12, _kCFStreamErrorCodeKey=8, NSLocalizedDescription=A server with the specified hostname could not be found.}

I'm running:

Xcode Version 11.2.1 (11B53)
iPad running iOS 13.3.1

Here are the Firebase pod versions that I'm using. I've run 'pod update' to get the latest:

  - Firebase/Analytics (6.20.0):
    - Firebase/Core
  - Firebase/Core (6.20.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.3.1)
  - Firebase/CoreOnly (6.20.0):
    - FirebaseCore (= 6.6.4)
  - Firebase/Database (6.20.0):
    - Firebase/CoreOnly
    - FirebaseDatabase (~> 6.1.4)
  - Firebase/DynamicLinks (6.20.0):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (~> 4.0.7)
  - FirebaseAnalytics (6.3.1):
    - FirebaseCore (~> 6.6)
    - FirebaseInstallations (~> 1.1)
  - FirebaseAnalyticsInterop (1.5.0)
  - FirebaseAuthInterop (1.1.0)
  - FirebaseCore (6.6.4):
    - FirebaseCoreDiagnostics (~> 1.2)
    - FirebaseCoreDiagnosticsInterop (~> 1.2)
  - FirebaseCoreDiagnostics (1.2.2):
    - FirebaseCoreDiagnosticsInterop (~> 1.2)
  - FirebaseCoreDiagnosticsInterop (1.2.0)
  - FirebaseDatabase (6.1.4):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 6.0)
  - FirebaseDynamicLinks (4.0.7):
    - FirebaseAnalyticsInterop (~> 1.3)
    - FirebaseCore (~> 6.2)
  - FirebaseInstallations (1.1.0):
    - FirebaseCore (~> 6.6)

Hello, I've tested my IPv6 using https://test-ipv6.com and it says I (my ISP) don't have any IPv6 compatibility.

And this causes my app freeze on the first launch. Relaunching helps. I'm also getting the same error messages

I can also definitely reproduce. And if this occurs in your app's startup sequence, it will hang the app, with iOS killing it after 20-odd seconds...

Is there a fix for this? Dynamic links don't open the app and I am sure this might be the issue. If the attribution does not install, then the app will not open. Please help

Is there a fix for this? Dynamic links don't open the app and I am sure this might be the issue. If the attribution does not install, then the app will not open. Please help

I was able to work around this by moving Firebase initialization out of the app's startup sequence, i.e. delaying it much as possible, and not having it in AppDelegate.init or AppDelegate.appDidFinishLaunching. This fix hasn't gone into production for our app yet, so we'll still need to see if it actually works. It's a hard one to reproduce, but when you do, you can't get out of it, unless you reinstall the app.

Is there a fix for this? Dynamic links don't open the app and I am sure this might be the issue. If the attribution does not install, then the app will not open. Please help

I was able to work around this by moving Firebase initialization out of the app's startup sequence, i.e. delaying it much as possible, and not having it in AppDelegate.init or AppDelegate.appDidFinishLaunching. This fix hasn't gone into production for our app yet, so we'll still need to see if it actually works. It's a hard one to reproduce, but when you do, you can't get out of it, unless you reinstall the app.

This is kind of an issue for me as I’m working with a Flutter app and barely have to touch the actual iOS code, but I will try and take a look at that to see what’s going on. I did realize that the links work on the simulator but not on a real device, which is weird

I ran into this myself today. Firebase 6.23.0, using Flutter. Happy to provide any data but basically I'm getting the same errors that others have listed. Works fine on Android. It was working once upon a time on IOS 13.3 and 13.4, but after a pod update (I think), I have not been able to fix it.

Yeah , same problem.
`2020-05-03 20:05:48.492994+0300 [839:408719] Task <4D1203B1-9569-4E97-84BB-5929DF9C4FD5>.<2> HTTP load failed, 0/0 bytes (error code: -1003 [12:8])

2020-05-03 n20:05:48.494219+0300 [839:408719] Task <4D1203B1-9569-4E97-84BB-5929DF9C4FD5>.<2> finished with error [-1003] Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={NSUnderlyingError=0x283d02c70 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorCodeKey=8, _kCFStreamErrorDomainKey=12}}, NSErrorFailingURLStringKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=, NSErrorFailingURLKey=https://firebasedynamiclinks-ipv6.googleapis.com/v1/installAttribution?key=, _kCFStreamErrorDomainKey=12, _kCFStreamErrorCodeKey=8, NSLocalizedDescription=A server with the specified hostname could not be found.}

I got the same issue, Is there any update?

Same issue here

same issue here

Same issue here, too.

Any solution for this?

Same here...

It is working by uploading to hardware device.

@harrygt @fbuland pls verify - Is this issue reproduced for your projects on real equipment and in a real environment or not?

I reproduced this issue on a physical iPhone 5s with iOS 12.4.6 and a physical iPhone 6s with iOS 13.4.1. Both are using Wifi connection.
I don't have the opportunity yet to test on mobile network.

In my Podfile.lock : FirebaseDynamicLinks (~> 4.0.8). How to upgrade to v.4.1.0 ?

same here
facing this issue in RN

  - Firebase/DynamicLinks (6.25.0):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (~> 4.0.8)

@alif1993 that is abusive. 1) these are humans on the other side of your keyboard 2) this SDK is marvellous but also marvellously complicated, how's your migration to IPv6 going for instance? To imply low quality based on this issue, and to infer some kind of lack of care is so insulting.

Hello, Folks! I have same issue here. Seems that this merge request didn't help.

The pull request (in review comments) actually mentioned it was a separate issue, but the developer who proposed it was aware it wouldn't be fixed

I quote @eldhosembabu from #5665 (comment)

Its not actually, for fixing #5032 we need to optimize the calls i guess for that. Currently we are doing ipv4 and ipv6 calls parallel and consolidate the results which needs to be serialized. In this current fix, I'm just making sure we don't repeat checkforpending calls when there is an error in the previous one.

and one could assume from "this current fix" that's this one is probably on an issue board somewhere pending attention

worth a mention that the SDK is open source, and anyone can propose a PR...you can also hack out the ipv6 code directly perhaps, or do anything you like to get your project moving

@mikehardy I agree that I went too far, but when our team has a deadline and the product was supposed to be delivered two weeks ago and coz of this bug which is so weird since everything is okay on Android and it happens on IOS. You are right, it's my fault, I should have checked all our product feature in pre-production. I APOLOGIZE to the team, I left that comment after four consecutive days of searching:) which was completely a wrong move:(

@a-h Thanks for the terrific bug report.

And everyone: I'm sorry that we're having trouble making progress on this issue. We'll continue to try to work with the team to get some focus here. In the meantime, we'd be happy to evaluate any PRs.

Hehey! Any progress on this? Also, if someone has a workaround, I would gladly like to try it out!

Hey! Same problem at my end. I'm inside IPV4 network at my local ISP and firebase tries to connect to ipv6 domain which cannot be resolved from ipv4 network.

Same issue here...

- Firebase/DynamicLinks (6.27.1): - Firebase/CoreOnly - FirebaseDynamicLinks (~> 4.1.0)

It's been months there's still nothing on this?

@IsaiahJTurner you have to dig a bit but there is activity, it is just a mix of different issues and internal conversations. Specifically examine discussion here: #5966 - a rejected PR that might have fixed this but had some unacceptable backend consequence - from 9 days ago, so I'd infer it's an active topic, just without messaging here for status

Does this issue still active? Maybe someone has something like workaround/hack or we still need to find a solution?

Any solution to this? It's been at least 6 months without a fix.

Any solution to this? would gladly get one

Hi everyone,

Sorry for the delays and lack of communication here, but this issue is now resolved. We were originally worried that by switching to the base API that doesn't specify ipv4 vs ipv6 would lose accuracy based on attribution, but have determined that it's a small corner case and an acceptable tradeoff from a performance and confusion standpoint (printing error logs when it may be working as intended).

Thanks for your patience as we worked through this, this change will be available in the next release expected sometime next week.