We have been testing our iOS app and QUIC for a while now, and I'd like to share some more observations. In short, Even though we do get the Alt-Scv header from our backend, the app might utilize HTTP/3 on one day and completely ignore it on other days. A simple test client for MacOS confirmed the behaviour is the same not only with our backend but also e.g. quic.nginx.org and cloudflare-quic.com. Our metrics say that only about 30% of our clients get QUIC. While researching here and there on the web we came to the /Library/Preferences/com.apple.networkd.plist file, and its enable_quic parameter was something that surely caught our eyes. With this we surveyed some of our colleagues. It turned out that when they had this flag enabled (set to 1) - h3 was working both in Safari and the test client, otherwise (set to 0) the best they could get was HTTP/2 (roughly half of them). To me this feels not aligned well with the description of the QUIC discovery from WWDC. Would you please explain the rationale behind the enabling logic described above? This all depends upon how CFNetwork (the library the runs URLSession) classifies the hostname being used. Is there anything (besides assumesHTTP3Capable) we can do to help CFNetwork better classify the hostname for QUIC?

Having a similar problem with Xcode 14.1: it constantly fails loading the list of all app versions and some other information like Hang reports from Connect. "Xcode failed to load app versions for *. * failed with error: There was a network error: The request timed out." So disappointing..