Hi Quinn, sorry for revisiting this old question. Thank you so much for the explanation. I've been testing on Network Framework while app in background, and I have some further questions. From TN2277 in section Data Socket: If you do leave your data socket open when going into the background, you must correctly handle errors on that socket. What is the error handling required by the system different from a "normal socket error handling"? The example given in the TN2772 was handling EBADF on socket reclaimed. Is there more information about what are the other errors we should take care of? About suspension. The doc was quite vague about the (app) becomes eligible for suspension when it stops doing the thing that prevented it from being suspend I did more testing on this by creating a long running task which keep writing into the socket. It seems the application would be kept alive as long as the task is running. (It ran for about 3 hours before I stopped it. ) From my investigation, it seems that the Network Framework handler like nw_connection_set_state_changed_handler would be proceed as normal when the application in background. Does it means that the socket IO events would prevent the app from being suspended? Also, probably because the socket was kept alive, I've never got error like EBADF in the tests above. Would you have any recommendation for a proper way to verify if the socket is affected by the suspension...?

Here’s an update on my findings in case anyone else is interested in this topic. I attempted to keep the connection open while the app is in the background. As Quinn mentioned, when the app is backgrounded, the socket essentially "goes deaf." When I bring the app back to the foreground, the connection will encounters the ECONNABORTED error code from IO handlers. My main issue is determining how to handle the connection after resuming the app. If the app was suspended but the connection is still viable, I was able to continue using the connection for further IO events after resume the app. However, if the connection is defunct, I have to recreate a new connection. Unfortunately, I haven’t found a reliable way to distinguish between these two scenarios. For now, I’ve opted to always close and re-create the connection upon receiving an ECONNABORTED error, and I’m leaving it at that. If anyone has insights on detecting when a socket resource has been reclaimed, I’d love to hear any suggestions for improvement!

Thanks for following up! My request stems from the requirements of the MQTT protocol. According to the protocol, the client is expected to keep retrying the connection to the server until either the user explicitly stops it or a retry limit is reached. In case B, where there’s a temporary issue like a "data center outage," the client should continue sending "Connect" requests until the server get recovered from "asteroid strike" (or until it hits the retry limit). In scenario C, however, we know the connection is permanently defunct. In this case, there’s no value in endlessly retrying, as the "Connect" requests will not succeed. We'd prefer to prompt the user to establish a new connection rather than engaging in pointless retry attempts.

Hi olivierfromcambridge, Is there any update on this? Or any examples of "having a test target an app"? I'm encountering the same situation—I have a data protection keychain implemented and would like to set up unit tests for it. Any guidance would be greatly appreciated!

Thank you so much for the detailed explanation and suggestion!! I will go with suggestions that only one dispatch queue will access the task list.