Sorry about my late reply as I was out for the last week. So, this phone is unable to talk to your server at all? Yes, that's correct. We're looking into adding a HTTP/1.1 endpoint in the server as a backup. But that comes with own issues (TLS etc). Any ideas when / in what cases assumesHTTP3Capable does not take effect? P.S. the same phone also used to work a few months ago. But we cannot remember what updates have happened on this phone (currently it is running iOS 16.0.2). Thanks!

I compared the console log from a phone with this problem and another one that works: good case: (iOS 17.4) Connection 0: creating secure tcp or quic connection Connection 4: enabling TLS bad case: (iOS 16.0.2) Connection 1: enabling TLS I.e. the bad case is missing the log line "creating secure tcp or quic connection". Any ideas how this could happen?

I have encountered a related problem (see https://developer.apple.com/forums/thread/758255). I am wondering if you saw QUIC always enabled if assumesHTTP3Capable is true? (regardless enable_quic parameter in /Library/Preferences/com.apple.networkd.plist) In our case, we always use assumesHTTP3Capable to ensure a request is processed by QUIC. But we hit a blocker when a phone running iOS 16.0.2 always uses TCP (h2 I suppose) for some reason. (The backend only supports H3 / QUIC).

the ability to do that would be super useful and I encourage you to file an enhancement request for us to add it as a property to the task metrics API. Please post your bug number, just for the record. Thank you for your suggestion! I've opened a ticket: FB14017046 . And thanks a lot for your detailed example! It's helpful! (I finally realized that I should use Console app to view the system log). I can find the connection details now. One thing I didn't understand is: why is there "parent" and "child" connection / flow? Are they the "connection" and "stream" in the context of HTTP2/3 ? But even then, how can there be 3 levels of connection ID like C2.1.2?

At the API level? Or while debugging? Either would help. I am using URLSession (with QUIC only) and the app has multiple URLSession and many network requests. My goal is to figure out which request (or connection) is causing these messages. Right now I am going through the app code and making a bit progress, but still don't have a reliable way to debug such messages quickly. For debugging, the key thing in that log is this: [C1]. Is there a way for me to log this ID in my app log as well? How do I access this ID info given a URLSession ? You can then correlate that logging with the logging done by Network framework to work out which URLSession request is... I can log local IP / port / remote IP / port tuples, but how do I correlate to the message in this question? Maybe I missed something obvious?

I tried to use .edgesIgnoringSafeArea([.top]) modifier, but MyView still shift when NavigationBar hides, just shifting a different amount.

Instead of using buttons, use images: app.images["cardMenu"].tap()

Another question I have is: based on NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway? , can I opt to connect to the server anyway programmatically?

Adding more info here as it's over the limit of a comment. I used WireShark to capture the packets from the real device. Looks like when the upload task is in a foreground URLSession, the session establishes http/3 QUIC connection without trying / waiting Http/1.1 first. This is expected as I am using assumesHTTP3Capable = true. But in a background URLSession, looks like the system tries to talk to Http/1.1 first, and as the server only talks http/3, the task fails to start. Is this behavior expected? If yes, why the difference between a foreground session and a background session?

I have found the root cause: I missed setting "Objective-C Bridging Header" for Release. The reason that the build worked for both the simulator and the device is that both of them are running the app in Debug mode, not in Release mode. But Archive requires building in Release mode. Now I've added the bridging header in the Build Setting for Release mode and the issue is gone.

Finally I created a new AVPlayer for each item, i.e. no longer replacing an old item with a new item in the same AVPlayer and the issue is gone.

I tried something different: instead of wrapping UIView using UIViewRepresentable, I changed to wrap AVPlayerViewController using UIViewControllerRepresentable, and then don't use my own video controls anymore. It seems like: If I share the same AVPlayer for each video item (i.e. each AVPlayerViewController), then I still have the video track freezing problem when scrolling between video items. If I create a new AVPlayer for each video item, then the video track freezing problem is gone. (I'm yet to find the best way to dismiss / stop AVPlayerViewController in wrapping swiftUI when it's scrolling off screen, any suggestions?)

Never mind, I changed to a different approach to use AVPlayerLayer instead, and now it works.

Here is the screen shot that shows Xcode disables the constraints setting for the image view inside the scroll view:

Can I ask what version of XCode are you using? I'm thinking whether it's a bug in XCode. (I am using XCode 12.5.1 on macOS Big Sur, and using Objective-C).