Thanks again for the extensive answer! To be clear, we got things covered regarding not being able to continue doing work in the background. What was unexpected to us however was the behaviour of the setServiceStatus method, but now I understand its use-case is different from what we thought it was. Especially because one of the values of the enum is connecting we thought we should use it to track the connection state from the client side of things. And then you run into trouble as soon as the application is moved to the background because you will lose the ability to update the state, so the last state will stick. And as the PTT UI actually is only accessible when your app is in the background, this didn't make sense to us.

Scratch that. Setting the state to .connecting doesn't trigger anything in the system UI either it seems. So the only workaround I can think of is setting the state always to .ready when the app enters the background. Which seems fishy.

Hmm. Maybe the problem is that I use .unavailable while disconnected, maybe I should use .connecting, even though I might not be truly reconnecting at that time. It does seem the framework does use that to activate the app when I show the PTT UI.

We are running into an issue updating the PTT service status when our app is in the background. In one of your earlier responses you mentioned that keeping the PTT connection alive in the background is common: "...is actually pretty common to most PTT apps, as it helps keep the conversation stream live/current compared to relying entirely on PTT pushes." However, what we are currently observing is different. When the debugger is not attached, it appears that all tasks are immediately suspended once the app goes to the background. When the app returns to the foreground, the URLSessionWebSocketTask fails with: Domain: NSPOSIXErrorDomain Code: 53 This effectively means we must immediately fall back to push notifications whenever the app backgrounds. While this works, it is not ideal. The larger issue is that this failure is only detected after the app resumes, which means we cannot update the service status on PTChannelManager while the app is still in the background. This leads to two different UI behaviors in the PTT interface: Case 1: Connection active when entering background The PTT UI still allows pressing the Talk button. Pressing Talk triggers a reconnect, which works. Case 2: Network lost before entering background and later restored The PTT UI remains disabled (e.g. the Talk button stays disabled). The service status is only corrected after reopening the app. From your earlier response, I understood that some background activity to keep the conversation stream current should be possible. If background work is not allowed in this situation, I would expect the app to be woken when the PTT Dynamic Island UI is opened so it can refresh the service status and update the Talk button state. Are we missing something in how background modes should be configured for PTT apps, or is this the expected behavior for WebSocket connections used with Push-to-Talk? Thanks!

Wow, thank you for the extensive background information!

I indeed used a simplified example for demonstration purposes where I didn't add the microphone permission and audio session setup. In my real application I do. However, your answer did trigger me to check that code again, and I noticed that I accidentally added .mixWithOthers to the options. And it seems that causes the audio session not to get activated when running in the background. So I removed that option and now everything is running fine! Also great to hear that it is ok to keep things running in the background when there is an active PTT session. It indeed improves the conversation flow a lot. Thanks!

I've created an example app to demonstrate my problem. It can be found here: https://github.com/egeniq/ptt-audio-activation-test-ios To reproduce, do the following: Change team selection in Xcode. Run the app. Choose join. Tap on the "Set remote participant NOW" button. See in the log output that the audio session gets activated. Tap on the "Clear remote participant" button. See in the log output that the audio session gets deactivated. Tap on the "Set remote participant after 5s" button. Immediately go back to your phone's homescreen. After 5s see in the log output that the remote participant is successfully set. However also note that no audio session activation occurs.