It seems that the issue is still around or a new one creeped in? I can see a number of crashes in Crashlytics on iOS 15.5.0. Crashed: com.apple.network.connections 0 libquic.dylib 0x6b06c qlog_abort_internal + 276 1 libquic.dylib 0x6b058 qlog_abort_internal + 256 2 libquic.dylib 0x239e4 quic_send_frames_for_key_state + 3928 3 libquic.dylib 0x301e0 quic_migration_probe_path + 1532 4 libquic.dylib 0x33010 quic_migration_new_cid + 156 5 libquic.dylib 0x110e0 quic_frame_process_NEW_CONNECTION_ID + 4080 6 libquic.dylib 0x647cc quic_frame_process + 140 7 libquic.dylib 0x169c4 quic_process_inbound + 1376 8 libnetwork.dylib 0x5dd5f0 nw_protocol_data_access_buffer + 1064 9 libquic.dylib 0x157cc __quic_handle_inbound_block_invoke + 152 10 libquic.dylib 0x10bc quic_handle_inbound + 124 11 libnetwork.dylib 0x5c048c __nw_protocol_implementation_get_input_internal_block_invoke + 136 12 libnetwork.dylib 0x5bf60c nw_protocol_implementation_get_input_internal + 252 13 libnetwork.dylib 0x5be7f8 nw_protocol_implementation_read + 436 14 libnetwork.dylib 0x5bdf08 nw_protocol_implementation_input_available + 96 15 libnetwork.dylib 0x514698 nw_channel_add_input_frames + 9236 16 libnetwork.dylib 0x512198 nw_channel_update_input_source + 328 17 libnetwork.dylib 0x5113a4 __nw_channel_create_block_invoke.29 + 72 18 libdispatch.dylib 0x3a30 _dispatch_client_callout + 20 19 libdispatch.dylib 0x6eec _dispatch_continuation_pop + 500 20 libdispatch.dylib 0x1a13c _dispatch_source_invoke + 1596 21 libdispatch.dylib 0xcf80 _dispatch_workloop_invoke + 1784 22 libdispatch.dylib 0x16500 _dispatch_workloop_worker_thread + 648 23 libsystem_pthread.dylib 0x10bc _pthread_wqthread + 288 24 libsystem_pthread.dylib 0xe5c start_wqthread + 8

I started to experience slow incremental builds after setting the defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 1. Once I set it back to 0, restarted Xcode and removed derived data all is looking good. Will take a closer look later what is the actual issue when it's set to 1.

You would need something like these functions when the app is backgrounded and then foregrounded:     func enterIntoBackground() {         if #available(iOS 14, *) {             if self.player?.rate == 1 {                 DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) { [weak self] in                     if self?.player?.rate == 0 {                         self?.playerViewController?.player = nil                         self?.player?.play()                     }                 }             }         } else {             self.playerViewController?.player = nil         }     }     func enterIntoForeground() {         if #available(iOS 14, *) {             // When the phone was locked in full screen mode             guard let vc = self.playerViewController else { return }             if vc.player == nil {                 vc.player = self.player             }         } else {             self.playerViewController?.player = self.player         }     }

The issue has been resolved in iOS 14 Beta 3

It's great news that you made it working but it also seems that there is a bug in the implementation. In the opening handshake the iOS client sends a “Sec-WebSocket-Extensions: permessage-deflate” header but the server declines it by the same header is not included in the response. The iOS client doesn’t respect the negotiations as it still tries to send the message compressed by setting the RSV1 bit as 1 in the WebSocket layer. As it’s not what has been negotiated the Websocket Connection fails according to the protocol. “RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated which defines meanings for non-zero values. If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST Fail the WebSocket Connection.”

I'm experiencing the same thing. It seems that a new header field has been added: Sec-WebSocket-Extensions permessage-deflate The issue is not with the connection but with the messages as they are compressed now at certain cases. Based on the length of the message being sent, it will either send it as text/binary or encoded text/binary. The limit seems to be at 8 characters or 16 numbers when sent it as a data. 7 characters like "aaaaaaa" works fine as it's only sent as binary, while "aaaaaaaa" comes back with a 1002 error code as it's been sent as encoded binary. First I thought it's just our WebSocket client but testing it with wss://echo.websocket.org gives the same result. Anybody from the Apple developers could point us if it's something that we are missing from the server config or is it a bug?

I've changed my WebSocket implementation to URLSessionWebSocketTask and can see the same issue in the crash reporting tool.No clear way to reproduce the issue yet. Here is some stack trace if maybe it can help.Crashed: NSOperationQueue 0x15fd97930 (QOS: UNSPECIFIED) 0 libswiftCore.dylib 0x1b8317aa4 specialized _assertionFailure(_:_:file:line:flags:) + 440 1 libswiftCore.dylib 0x1b813471c _assertionFailure(_:_:file:line:flags:) + 32 2 libswiftFoundation.dylib 0x1e0700644 partial apply for closure #1 in NSURLSessionWebSocketTask.receive(completionHandler:) + 404 3 libswiftFoundation.dylib 0x1e06a2e30 thunk for @escaping @callee_guaranteed (@guaranteed NSURLSessionWebSocketMessage?, @guaranteed Error?) -> () + 80 4 Foundation 0x1ab21f3a0 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16 5 Foundation 0x1ab1290c8 -[NSBlockOperation main] + 100 6 Foundation 0x1ab221628 __NSOPERATION_IS_INVOKING_MAIN__ + 20 7 Foundation 0x1ab128d60 -[NSOperation start] + 732 8 Foundation 0x1ab222020 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 20 9 Foundation 0x1ab221aec __NSOQSchedule_f + 180 10 libdispatch.dylib 0x1aaad97dc _dispatch_block_async_invoke2 + 104 11 libdispatch.dylib 0x1aab27184 _dispatch_client_callout + 16 12 libdispatch.dylib 0x1aaacfa3c _dispatch_continuation_pop$VARIANT$mp + 412 13 libdispatch.dylib 0x1aaacf190 _dispatch_async_redirect_invoke + 600 14 libdispatch.dylib 0x1aaadbfa4 _dispatch_root_queue_drain + 376 15 libdispatch.dylib 0x1aaadc770 _dispatch_worker_thread2 + 128 16 libsystem_pthread.dylib 0x1aab76b48 _pthread_wqthread + 212 17 libsystem_pthread.dylib 0x1aab79760 start_wqthread + 8Xcode 11.3.1 (11C504)iOS 13.3.1 (17D50)