I did not get further requests after the cancel.The cancel is still confusing to me as I'm testing locally using iOS simulator and local server, which has very low latency for the response. And it seems it was cancelled after 3 times of dataRequest respondWithData().

I compared the sequence of requests with a regular case when AVPlayer is created with a http URL without using delegate. I have two observations:1. In both cases, AVPlayer has first request asking for ContentInfo and range 0-1 (2 bytes) and 2nd request asking for the whole range (full length) of the video asset.2. In regular case, AVPlayer seems to "cancel" / "stop" the 2nd request as well, after receiving some (around 100k bytes) data.3. In regular caes, AVPlayer will continue to send 3rd request with requested offset following the 2nd request data received. But in the problematic delegate case, there was not 3rd request. So, now the question is, why didn't the delegate get a 3rd request from AVPlayer?

I found the problem. The reason is that AVPlayerItem (and AVAsset) cannot handle a URL for video if there is no known file extension, e.g. something like ".mp4".By observing the "status" key of AVPlayerItem, I found the error reason is "This media format is not supported" even though I have already set the content-type as "video/mp4" in ContentInformationRequest.Anyway, after manually adding ".mp4" in the URL, I was able to get additional loading requests after the 2nd request was cancelled. And the video playback works now 🙂 .Btw, this bug / behavior was reported on 2012, but it seems still not fixed. http://openradar.appspot.com/radar?id=1516408

The third-party framework (Cronet from chromium) I am using was not provided as xcframeworks. Its source code is available but has its own build script (not Xcode). I will look into it but not having high hope per my understanding.

Sorry about my late response. I am trying to use iPhone to communicate with other devices in the same WiFi LAN, and wondering if can use TDLS to reduce the load on the WiFi router. If not TDLS, is there any other thing I can use for iPhone to achieve the goal? Thanks.

To clarify 2 things, (1) I was able to set constraints between the scroll view and its superview, i.e. the Content View of the cell. (2) Xcode was not able to fix the "missing constraints" automatically, I tried that.

@Claude31 thanks for your response! My main problem is that XCode does not allow me to do the step in your "Create a UIView": "Define the constraints with respect to the scrollView (Superview)" . I.e. I am able to set constraints for the scroll view, but cannot set any constraints for the image view inside the scroll view. Please see attached screen shot of my current constraints list of 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).

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

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

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

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

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?

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?