- User opens an app, which loads a site in SFSafariViewController - Site makes use of WebRTC, plays remote media in a <video> element, and uses WebSocket for connecting to the control server - User returns to home screen (aka app with SFSafariViewController goes into background) - User spends anywhere from seconds to a minute away from the app (e.g., writes a text message, dismisses a notification, rejects an incoming call, takes a photo) - User returns to the app with SFSafariViewController Expected: - Remote streams are playing - Signaling channel is open - JS code ran unthrottled in the background - (Extended goal) If camera/microphone was not used by any other app, their streams have not "ended" while the app is in the background, the behavior currently seen in WKWebView, Safari, or a site open as home screen app. Actual: - Remote streams (<video> elements) may be stuck on black screen - RTCPeerConnections may have been killed - Signaling (WebSocket) connection is likely killed within ~30 seconds away from the app - While app was in background, no audio was being played beyond ~1 second after minimizing the app (Control Center shows the site <title> with active playback for 1 second after minimizing, then it clears to "no playback" state) - Camera and microphone streams have "ended" and new getUserMedia call has to be made This can also be (partially) reproduced with a simple page playing <audio>. When SFSafariViewController is taken to the background, playback is stopped. It seems to have always been the case, so no regression here. The behavior is unexpected, however, and requires iOS-specific code for handling (sometimes partially) broken state.
<rdar://problem/78462486>
Thanks for filing Teodor. Is there a test app available?