Post

Replies

Boosts

Views

Activity

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: 5a1981f90bb30827121324d4b33198d58de9b9d68e3508b64f0aabc18bbc0e53The 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? Configure and commit the capture session on the dedicated capture executor. Attach the session to the preview layer on MainActor. Call startRunning() on the capture executor. Perform ordinary preview layout on MainActor while capture runs. Call stopRunning() on the capture executor. 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 = nilis 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
0
0
27
4h
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: 5a1981f90bb30827121324d4b33198d58de9b9d68e3508b64f0aabc18bbc0e53The 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? Configure and commit the capture session on the dedicated capture executor. Attach the session to the preview layer on MainActor. Call startRunning() on the capture executor. Perform ordinary preview layout on MainActor while capture runs. Call stopRunning() on the capture executor. 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 = nilis 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
Replies
0
Boosts
0
Views
27
Activity
4h