On iOS, SCStreamConfiguration.excludesCurrentProcessAudio appears to do nothing. Audio produced by our own process is captured at full level, so there is currently no way to capture device audio while excluding what our app is playing. Measurement (deterministic probe, 2026-08-08): Our app plays a 1 kHz tone at -4.9 dBFS RMS from its own process while capturing device audio with SCStreamConfiguration.capturesAudio = true and excludesCurrentProcessAudio = true. The configuration in force is read back from the stream and logged, so we know the flag is actually set. The captured audio contained our own tone at -4.9 dBFS peak. Separation = 0.0 dB. 1,573 audio sample buffers analyzed over 31.5 s (16 kHz mono, 50 buffers/s), zero analysis failures, and the run was reproduced twice about 3 hours apart with byte-identical verdicts. Environment for that run: iPhone 16 Pro (iPhone17,1), iOS 27.0, built with Xcode 27 beta 4 (27A5228h) against the iOS 27 SDK, installed directly from Xcode. Still reproducing on the current build: on iOS 27.0 (24A5418b) our shipping capture path still receives our own playback. In production we now have to cancel it ourselves - we align our playback buffer to the captured stream by cross-correlation and subtract it. The correlation between the captured signal and our own playback sits at |r| = 0.65-0.85 in the affected segments, i.e. the capture is dominated by a copy of our own output, exactly what excludesCurrentProcessAudio is supposed to remove. Doing this subtraction in-process costs real CPU and only works while we can hold a delay lock. Why this is blocking: RPSampleBufferType.audioApp is deprecated as of iOS 27 and the documentation points to ScreenCaptureKit as the replacement. With excludesCurrentProcessAudio non-functional there is no supported path on iOS to capture device audio while excluding one's own process. Our app is a real-time dubbing app - it captures foreign-language audio, transcribes it, and plays back a translated voice - so our own output re-entering the capture is fed straight back into transcription and corrupts the session. My questions: (1) Is excludesCurrentProcessAudio expected to be functional on iOS 27, or is it macOS-only in practice? The documentation does not mark it as unavailable on iOS. (2) If it is expected to work, is there anything the app must do besides setting it on the SCStreamConfiguration used to start the stream? (3) If it is not going to work on iOS, what is the supported way to exclude the current process's audio from a ScreenCaptureKit capture, now that RPSampleBufferType.audioApp is deprecated? Filed as FB24170972 on 2026-08-08, with the full JSON event logs from both probe runs attached. There has been no response on the Feedback, which is why I am raising it here.

On iOS, ScreenCaptureKit terminates an SCStream when the app is backgrounded unless the app declares UIBackgroundModes: screen-capture. The delegate reports SCStreamError code -3824 (SCStreamError.Code.missingBackgroundMode). Adding screen-capture to UIBackgroundModes - the value Apple's own iOS 27 ScreenCaptureKit sample code declares - makes App Store Connect reject the upload: error: exportArchive Invalid Info.plist value. The Info.plist key UIBackgroundModes contains an invalid value: 'screen-capture'. So the app cannot be distributed at all, not even to TestFlight internal testers. We have ruled out simply keeping the process alive: running a continuous silent AVAudioEngine under the audio background mode keeps the app running but does not prevent -3824, which is consistent with the framework performing an explicit background-mode check rather than the stream dying from process suspension. One observation that may explain why this has gone unnoticed: Apple's sample is installed directly from Xcode and therefore never passes through App Store Connect's upload validation, so a mismatch between the sample's Info.plist and App Store Connect's allowlist would not be visible when testing the sample internally. My question is which of these three describes the actual status of screen-capture for third-party iOS apps: (1) App Store Connect's allowlist has not yet been updated for iOS 27, and this will resolve on its own. (2) screen-capture requires an entitlement or a specially provisioned profile we have not requested. If so, which one, and how is it requested? (3) screen-capture is restricted to Apple's own or system applications and is not available to third-party App Store apps by design. I could not find screen-capture documented on the general UIBackgroundModes page, which is why I cannot tell these apart. Filed as FB24169650. Device: iPhone 16 Pro, iOS 27.0 Built against the iOS 27 SDK, deployment target 17.0.