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.