Seems there's not much help to be expected, neither from developers nor Apple :-( I'm trying other channels.

Memory Consumption Issue makes working with XCode 13 impossible. Even right after a mac reboot/login, the memory request grows up to 40 GB and more right after launch of XCode. I can't find out the root cause as Xcode 13 was working since last official release 13, but suddenly the issue appeared as of today while not modifying the XCode installation (updates are configured as manual).

Does Xcode 13.1 RC help to fix the issue?

This doesn't seem to be related to a macOS release (issue happens also on Big Sur). Some parsing mechanism is getting in some deadlock populating the same process if unresponsive. I've filed an own bug report. Sharing the feedback report reference will not help here. At least, my report was identified as critical and I've got almost immediate processing response. I've requested a possible workaround to help out faster (than a XCode bug fix).

The issue appeared with XCode 13 official release. Probably, the last XCode 13 Beta was still fine.

Unfortunately, the issue is still present within XCode 13.2 RC in 1 of my complex iOS projects. I'll reopen the issue report to Apple.

The issue is still present in XCode 13.2 Final Release. This is a show stopper! Apple Devs, please soon fix the issue. Xcode is useless since 2 months. My project does not build anymore, neither with simulator or real device. Analysing the project does not work neither. Automatically running background tasks e.g. for Canvas prevent from continued software development (without user triggered build functionality). RAM memory consumption grows up to 100 GB and more. Included Swift packages compile correctly, but compilation of own modules lasts for ever in dead loop without compilation warning. There's some long lasting background build activity, if patient, the build process may finish (before the MBP resets). This behaviour is non deterministic: I've experienced the same project may compile/run after a build folder clean without any code change. I was somehow lucky to first progress with XCode 13.2 RC (13C90), but the local workaround does not work anymore. Please help out.

Build succeeded 17/12/2021 19:19 1731.0 seconds !!

Hey Quinn, Thanks for your feedback. Yes, the connection has to go via cellular network as the users are on the road. Refering to your mentioned steps: first connection enters the .failed(…) state once in poor reception area. This works perfect. No further states are reported any more for the same connection. Here's a trace of the states and error codes from 1st connection onwards: ... celluar network available ... [20:49:47.GMT+2] [NetworkManager:setupUDPConnection(lat:lon:):43 5] UDP in .preparing, available Interfaces: [pdp_ip0] --> OK [20:49:54.GMT+2] [NetworkManager:setupUDPConnection(lat:lon:):42 3] UDP in .ready, available Interfaces: [pdp_ip0] --> OK ... celluar network loss ... [21:15:12.GMT+2] [NetworkManager:setupUDPConnection():44 2] UDP in .failed: 57 The operation couldn't be completed. (Network.NWError error 57 - Socket is not connected), available Interfaces: [pdp_ip0] --> OK, state .failed [21:15:12.GMT+2] [NetworkManager:receiveUDPConnection ():912] Optional (unsatisfied (No network route)):The operation couldn't be completed. (Network.NWError error 57 - Socket is not connected) --> OK, state .failed (on downlink) [21:15:12.GMT+2] [NetworkManager:sendADSLdata():778] unsatisfied (No network route):POST beacons The operation couldn't be completed. (Network.NWError error 57 - Socket is not connected) --> OK, state .failed (on uplink) ... celluar network available (again) ... Even though the cellular network is available again (confirmed by load of a web site from within the app), the network state remains in .failed, and does not get updated anymore. So, the question is: should connection.stateUpdateHandler report a state update even a connection state previously turned .failed? You've mentioned the connection state should return to .ready under recovery of a strong network availability. This isn't the case. Is this already an origin of the issue?

OK, that"s what I've supposed. The state .failed is terminal. This is why I've implemented the re-connection with setupUDPConnection(). However, I'm not quite sure from where to recover. Here's my condensed implementation of setupUDPConnection(): self.connection.cancel() let udp = NWProtocolUDP.Options.init() udp.preferNoChecksum = false let params = NWParameters.init(dtls: nil, udp: udp) params.serviceClass = .responsiveData connection = NWConnection(host: NWEndpoint.Host.name(AppConstant.Web.urlWebSafeSky, nil), port: NWEndpoint.Port(rawValue: AppConstant.Web.urlWebSafeSkyPort)!, using: params) connection.stateUpdateHandler = { (newState) in switch (newState) { case .ready: self.receiveUDPConnection() break case .setup: // Nop break case .cancelled: // Nop break case .preparing: // Nop break case .waiting(let error): // Nop break case .failed(let error): // Cancel present connection // break default: break } self.handleStateChange() } connection.start(queue: queue)` But the connection using the same NWConnection instance (self.connection) does not succeed. Possibly, because the network reception is still weak. How does one get informed about re-availability of the RF network connection in order to start the above mentioned setupUDPConnection()?