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.