Swift 6: Supported AVCaptureSession actor isolation and MainActor preview attachment

I’m developing a SwiftUI camera preview for iPhone and iPad using Xcode 27.2 and Swift 6.4.2.

I’m looking for clarification about the supported concurrency boundary between an actor-owned AVCaptureSession and a MainActor-owned AVCaptureVideoPreviewLayer.

Environment
  • Xcode 27.2 (27B52)
  • Apple Swift 6.4.2
  • iPhoneOS SDK 27.2
  • Deployment target: iOS 26.0
  • Swift 6 language mode
  • Complete concurrency checking
  • Default actor isolation: MainActor
  • Approachable Concurrency enabled

The isolated compiler reproductions also explicitly enable NonisolatedNonsendingByDefault, InferIsolatedConformances, and MemberImportVisibility.

Architecture

The intended architecture follows the general pattern demonstrated in Apple’s AVCam sample:

  • A capture actor uses a dedicated DispatchSerialQueue executor.
  • The capture actor creates, configures, starts, and stops AVCaptureSession.
  • A MainActor adapter owns AVCaptureVideoPreviewLayer.
  • The preview layer retains the same session after attachment.

The capture actor retains its session reference because it must perform subsequent capture operations.

Compiler behavior

In a minimal reproduction, transferring the retained session directly to the MainActor adapter:

await preview.attach(session)

produces:

Sources/CaptureActor.swift:19:23:
error: sending 'session' risks causing data races
[#RegionIsolation::SendingRisksDataRace]

The compiler identifies a potential race between actor-isolated and MainActor-isolated uses.

This reproduction produces one error and zero warnings.

A second reproduction uses a small PreviewSource: Sendable value containing a private AVCaptureSession reference, with @preconcurrency import AVFoundation confined to that source file.

Its MainActor method attaches the session to the preview layer.

Under otherwise identical compiler settings, this second reproduction compiles with zero diagnostics.

We understand that compiler acceptance does not establish runtime safety and that the compatibility mechanism does not itself synchronize access to the retained session.

Apple AVCam reference

Apple’s official AVCam sample demonstrates a similar interoperability pattern:

  • CaptureService.swift: dedicated capture executor and retained preview source.
  • PreviewSource.swift: compatibility import and MainActor attachment.
  • CameraPreview.swift: preview-layer association.

Reference: Apple’s AVCam: Building a Camera App sample.

Pinned sample SHA-256:
5a1981f90bb30827121324d4b33198d58de9b9d68e3508b64f0aabc18bbc0e53

The sample revision date is not established; we are not assuming this archive is identical to the latest downloadable revision.

Questions
1. Supported Swift 6 interoperability pattern

Is the narrow PreviewSource compatibility approach demonstrated by AVCam the recommended way to associate an actor-retained AVCaptureSession with a MainActor-owned AVCaptureVideoPreviewLayer under complete Swift 6 concurrency checking?

Is there a newer recommended API, annotation, or ownership pattern?

2. Capture and preview synchronization

Is the following operation sequence supported?

  1. Configure and commit the capture session on the dedicated capture executor.
  2. Attach the session to the preview layer on MainActor.
  3. Call startRunning() on the capture executor.
  4. Perform ordinary preview layout on MainActor while capture runs.
  5. Call stopRunning() on the capture executor.
  6. Detach the session from the preview layer on MainActor.

Which preview-layer or preview-connection mutations, if any, must be excluded while startRunning() or stopRunning() is executing?

3. Supported detachment and release sequence

After stopRunning() returns and MainActor executes:

previewLayer.session = nil

is it supported to release the remaining application-held session references once application-owned observers and asynchronous consumers have terminated?

Does AVFoundation require or recommend any additional step before those references are released?

We are asking about the supported framework lifecycle contract, not assuming that application-level cancellation drains internal AVFoundation work.

Sources

AVCam: Building a camera app Overview
Apple’s official AVCam sample