On iOS/macOS 26, CNAssetSpatialAudioInfo(asset:) and CNAssetSpatialAudioInfo.assetContainsSpatialAudio(asset:) accept a spatial capture only when its spatial track is APAC-encoded which AVCaptureMovieFileOutput produces when the video codec is HEVC. An otherwise-identical ProRes capture, whose spatial track is LPCM (4-channel First-Order Ambisonics, kAudioChannelLayoutTag_HOA_ACN_SN3D | 4), is rejected with CNCinematicErrorDomain code 3 (CNCinematicErrorCodeIncomplete) "no eligible audio tracks in asset". This reproduces with Apple's own SpatialAudioCLI sample run on Apple's own stock iPhone captures, so it appears to be a property of the format/API rather than my code. I'd like to confirm whether this is intended, and find a supported way to obtain Audio-Mix-eligible spatial audio while still recording ProRes video (we use Apple Log/ProRes for color grading). Respectively, is wiring a manual AVAssetWriter setup the only way to manage spatial audio and ProRes video? Eligibility appears to require an APAC-encoded, exactly-4-channel FOA track. Because AVCaptureMovieFileOutput only writes APAC audio for HEVC (ProRes forces LPCM), ProRes spatial captures are never eligible — including Apple's own ProRes stock captures, which SpatialAudioCLI also rejects. Key finding: eligibility seems baked into the native APAC bitstream Starting from an eligible HEVC/APAC file, I used AVAssetReader/AVAssetWriter to re-encode only the FOA track (APAC → LPCM → APAC), leaving the AAC stereo track, the HEVC video, and the timed-metadata track untouched. The structurally-identical output is then rejected (code 3). Preserving the cinematic-audio metadata track is not sufficient. Re-encoding the APAC itself loses eligibility. This suggests the mix metadata that gates eligibility is carried inside the APAC bitstream and is produced only at capture time. Questions Is it intended that ProRes (LPCM FOA) spatial captures are not Audio-Mix-eligible via CNAssetSpatialAudioInfo, while HEVC (APAC FOA) captures are? Is this documented? Where exactly is the eligibility metadata stored — in the APAC bitstream, or in the cinematic-audio timed-metadata track (Re-encoding the APAC while preserving that metadata track still loses eligibility)? Is there any supported way to make an existing LPCM/ProRes FOA capture eligible after the fact (a transcode/encode path that produces the required APAC), or is native capture the only source? Any guidance, or a pointer to documentation, would be greatly appreciated. Thank you. Environment iPhone 16 Pro Max, iOS 26.x; macOS 26.2; Xcode 26.2.

We are developing a video processing app that applies CIFilter chains to video frames. To not force the user to keep the app foregrounded, we were happy to see the introduction of BGContinuedProcessingTask to continue processing when backgrounded. With iOS 26, I was excited to see the com.apple.developer.background-tasks.continued-processing.gpu entitlement, which should allow GPU access in the background. Even the article in the documentation provides "exporting video in a film-editing app" or "applying visual filters (HDR, etc) or compressing images for social media posts" as use cases. However, when I check BGTaskScheduler.shared.supportedResources.contains(.gpu) at runtime, it returns false on every iPhone I've tested (including iPhone 15 Pro and iPhone 16 Pro). From forum responses I've seen, it sounds like background GPU access is currently limited to iPad only. If that's the case, I have a few questions: Is this an intentional, permanent limitation — or is iPhone support planned for a future iOS release? What is the recommended approach for GPU-dependent background work on iPhone? My custom CIKernels are written in Metal (as Apple recommends since CIKL is deprecated), but Metal CIKernels cannot fall back to CPU rendering. This creates a situation where Apple's own deprecation guidance (migrate to Metal) conflicts with background processing realities (no GPU on iPhone). Should developers maintain deprecated CIKL kernel versions alongside Metal kernels purely as a CPU fallback for background execution? That feels like it defeats the purpose of the migration. It seems like a gap in the platform: the API exists, the entitlement exists, but the hardware support isn't there for the most common device category. Any clarity on Apple's direction here would be very helpful.