macOS/iOS 27 SDK: AVSampleBufferDisplayLayer is main-actor isolated, 12 warning sites in the renderer

[superuser404notfound]

Split out of #313, which is the build failure that led here and is fixed and released (6.12.1). This issue tracks what the 27 SDK change leaves behind, which is warnings only today.

What changed

In the macOS/iOS 27 beta 4 SDK, AVSampleBufferDisplayLayer is annotated @MainActor (whole class, reported by @jihongboo from the headers). The engine touches the layer from the decode thread, so every such access is now an isolation violation.

Why it is warnings and not errors

The annotation arrives through an ObjC import, which carries preconcurrency semantics. Measured against a ~20 line ObjC module (__attribute__((swift_attr("@MainActor"))) on the class, non-Sendable object property) with swiftc -typecheck -swift-version 6, Swift 6.3.3:

shape	severity
sync read of a main-actor property from a nonisolated context	warning
sync mutation of a main-actor property	warning
sync call of a main-actor method	warning, group #ImplicitStrongCapture... see note
non-Sendable value pulled out with await from nonisolated async	error

(the method call lands in the #ActorIsolatedCall group.)

Isolation violations against imported declarations are downgraded to warnings. The region rule that governs a non-Sendable value leaving the actor is not, which is why #313 saw exactly one error.

The hot path needs nothing

queueTarget is typed any AVQueuedSampleBufferRendering, and that protocol did not move to the main actor. In the reporter's build, queueTarget.isReadyForMoreMediaData (SampleBufferRenderer.swift:165), the enqueue path through let target = queueTarget (:342) and the diagnostic read (:368) produce no diagnostic at all. The per-frame calls from the decode thread are already legal.

The 12 sites

Acquisition of the target:

• SampleBufferRenderer.swift :158, :170, :177, :300 (displayLayer.sampleBufferRenderer)
• AudioOutput.swift :29, :43 (same, to hand the renderer to the synchronizer)

Layer-only API on the pre-18 branch:

• SampleBufferRenderer.swift :172, :179 (displayLayer.status / .error), :303, :305 (flushAndRemoveImage() / flush())

Layer configuration in the factory:

• SampleBufferRenderer.swift :184, :188 (videoGravity, preventsDisplaySleepDuringVideoPlayback)

Candidate shapes, not built

Caching sampleBufferRenderer in a stored let is the wrong shape: displayLayer is a private(set) var and is replaced when HDR output changes, so a stored renderer becomes a second source of truth that the next layer swap can forget to update. Same trap as #321.

What holds:

1. A @MainActor factory that produces the layer and its queue target together, so the pair can never disagree, and makeDisplayLayer becomes main-actor isolated on the way (covers :184, :188 for free).
2. Raising the platform floor to tvOS 18 / iOS 18 / macOS 15 and deleting the legacy branch, which removes :172, :179, :303, :305 outright. That is a major, see the floor-raise rule in Package.swift.

Trigger

Nothing is built now: the SDK can still move before GM and the diagnostics cost nothing today. Act when a beta or the GM turns any of the 12 into an error, or when a floor raise is on the table for other reasons.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HX5zV3Fcf7Nzq4DYGdXvQE

[superuser404notfound]

Three updates. None of them moves the fix, which stays parked.

The trigger now has a watcher

"Act when a beta or the GM turns one of these into an error" only works if something builds against a beta SDK, and nothing did. CI pins latest-stable, and these warnings are invisible from a consuming build, which is exactly why #313 arrived as an outside report instead of from here.

Added in 75d26f7, .github/workflows/beta-sdk-watch.yml: a separate weekly workflow, Beta SDK watch, that builds the package against the Xcode beta and reports the isolation sites. It runs on a schedule rather than on pushes, so a beta that hardens one of the twelve arrives as a failed scheduled run instead of a blocked merge.

The correction is worth naming, because the obvious spelling is a false green. runs-on: macos-15 with xcode-version: latest resolves to Xcode 26.3: that image carries no 27 at all, so the job passes while checking nothing, and a green like that reads as evidence. Xcode 27 sits on its own preview label, xcode-27, where it is the only and the default Xcode, so there is nothing to select.

First measurement, Xcode 27 beta 4

Runner image xcode-27-arm64, macOS 26.5.2, Xcode 27.0 (27A5228h), Apple Swift 6.4, SDK 27.0. swift build in Swift 6 language mode succeeds. Twelve diagnostics, all warnings, zero errors. The trigger has not fired.

The inventory reproduces exactly, with the line numbers refreshed against main (the ones in the description are from the reporter's older revision):

site	diagnostic
SampleBufferRenderer.swift:189	sampleBufferRenderer referenced from nonisolated (queueTarget)
SampleBufferRenderer.swift:201	sampleBufferRenderer (queueStatus)
SampleBufferRenderer.swift:203	status, legacy arm
SampleBufferRenderer.swift:208	sampleBufferRenderer (queueError)
SampleBufferRenderer.swift:210	error, legacy arm
SampleBufferRenderer.swift:215	videoGravity mutated from nonisolated
SampleBufferRenderer.swift:219	preventsDisplaySleepDuringVideoPlayback mutated from nonisolated
SampleBufferRenderer.swift:331	sampleBufferRenderer (flush)
SampleBufferRenderer.swift:334	call to flushAndRemoveImage(), #ActorIsolatedCall
SampleBufferRenderer.swift:336	call to flush(), #ActorIsolatedCall
AudioOutput.swift:29	sampleBufferRenderer (addRenderer)
AudioOutput.swift:43	sampleBufferRenderer (removeRenderer)

Two results come from what is missing rather than from what is listed. loadRenderMetrics does not appear, so the @MainActor plus completion-handler form from #313 holds against the real 27 SDK and not just against the 20-line model of it. No per-frame site appears either, so the reasoning about AVQueuedSampleBufferRendering staying off the main actor holds: the readiness gate, the enqueue and the diagnostic read are legal as written.

Option 2 costs more than "a major"

Raising the floor to tvOS 18 / iOS 18 / macOS 15 and deleting the legacy branch reads cheap because that branch looks like dead code. It is not. AetherPlayer ships at macOS 14.0 / iOS 17.0, so it takes the queueTarget == displayLayer arm and the addRenderer(displayLayer) arm today. The raise would cost a major here, a deployment-target raise there, and a break for every consumer below 18/18/15, in exchange for four of the twelve warnings. Not a trade worth making on its own, so it stays where it was: only if a floor raise is already happening for another reason.