Supporting Continuity Camera in your tvOS app

At a glance

Project structure

App/
└── ContinuityCameraApp.swift
Camera/
├── CaptureManager.swift
├── CaptureManager+ContinuityCamera.swift
├── CaptureManager+Observers.swift
└── CaptureType.swift
Media export/
├── AudioCapturer.swift
├── PhotoCapturer.swift
└── VideoCapturer.swift
Observers/
├── CaptureDeviceNotificationObserver.swift
├── PreferredCameraObserver.swift
└── VideoEffectsObserver.swift
Views/
├── ContentView.swift
├── CameraPreview.swift
├── AudioControls.swift
└── CaptureButton.swift

Structure observations

• Folders follow responsibilities rather than generic MVC layers.
• CaptureManager extensions separate device selection and observation mechanics without creating additional owners.
• Each exported medium has a dedicated capturer, while the shared camera session remains centralized.

Overall architecture

flowchart LR
    App["ContinuityCaptureApp"] --> Manager["CaptureManager"]
    App --> Photo["PhotoCapturer"]
    App --> Video["VideoCapturer"]
    App --> Audio["AudioCapturer"]
    App --> View["ContentView"]
    View --> Manager
    View --> Photo
    View --> Video
    View --> Audio
    Manager --> Session["AVCaptureSession"]
    Photo --> PhotoOutput["AVCapturePhotoOutput"]
    Video --> MovieOutput["AVCaptureMovieFileOutput"]
    PhotoOutput --> Session
    MovieOutput --> Session

Reference code

App/ContinuityCameraApp.swift:31 — the app root wires media outputs into the shared session, then injects every owner into the main view.

init() {
    captureManager.addOutput(photoCapturer.photoOutput)
    captureManager.addOutput(videoCapturer.movieFileOutput)
}

var body: some Scene {
    WindowGroup {
        ContentView(captureManager: captureManager,
                    photoCapturer: photoCapturer,
                    videoCapturer: videoCapturer,
                    audioCapturer: audioCapturer)
    }
}

Interpretation

The view composes the UI but does not construct capture infrastructure. Camera input and session configuration belong to CaptureManager; media-specific capture, export, and published state belong to the corresponding capturer.

Ownership and state

classDiagram
    ContinuityCaptureApp *-- CaptureManager : creates
    ContinuityCaptureApp *-- PhotoCapturer : creates
    ContinuityCaptureApp *-- VideoCapturer : creates
    ContinuityCaptureApp *-- AudioCapturer : creates
    CaptureManager *-- AVCaptureSession : owns
    CaptureManager *-- PreferredCameraObserver : owns
    CaptureManager *-- VideoEffectsObserver : owns
    CaptureManager *-- CaptureDeviceNotificationObserver : owns
    PhotoCapturer *-- AVCapturePhotoOutput : owns
    VideoCapturer *-- AVCaptureMovieFileOutput : owns
    AVCaptureSession o-- AVCaptureOutput : attaches
    ContentView --> CaptureManager : observes
    ContentView --> PhotoCapturer : observes
    ContentView --> VideoCapturer : observes
    ContentView --> AudioCapturer : observes

Ownership evidence

Camera/CaptureManager.swift:22 — the manager creates the session, derives its preview layer from that session, and retains observation adapters.

let session = AVCaptureSession()
let previewLayer: AVCaptureVideoPreviewLayer

var videoEffectsObvserver = VideoEffectsObserver()
var notificationObserver = CaptureManager.makeNotificationObserver()
var preferredCameraObserver = PreferredCameraObserver()

override init() {
    previewLayer = AVCaptureVideoPreviewLayer(session: session)
    super.init()
    preferredCameraObserver.handler = updateSystemPreferredCamera(_:)
}

Class and protocol design

The sample uses protocol orientation at framework boundaries through AVFoundation delegate conformances. It favors concrete app services and small typed closures over app-defined service protocols.

Access control

Reference code

Camera/CaptureManager.swift:33 — activeInput is intentionally module-visible, but it centralizes the remove/add side effects in one property.

internal var activeInput: AVCaptureDeviceInput? {
    willSet {
        if let oldInput = activeInput { session.removeInput(oldInput) }
    }
    didSet {
        if let newInput = activeInput { session.addInput(newInput) }
        isActive = (activeInput != nil)
    }
}

Media export/AudioCapturer.swift:27 — mutable engine internals are private, while UI-facing state is read-only outside the capturer.

private let avAudioEngine = AVAudioEngine()
private let avAudioSession = AVAudioSession.sharedInstance()

@Published private(set) var playingBackgroundNoise = false
@Published private(set) var canPlayRecordedAudio = false
@Published private(set) var isPlayingRecordedAudio = false

Logic ownership and placement

Design patterns

Main application flow

sequenceDiagram
    actor User
    participant View as ContentView
    participant Manager as CaptureManager
    participant Capturer as Selected capturer
    participant Output as AVFoundation output
    User->>View: Connect device or press shutter
    View->>Manager: select camera / start session
    User->>View: Capture photo, video, or audio
    View->>Capturer: capture command
    Capturer->>Output: begin capture
    Output-->>Capturer: delegate completion
    Capturer-->>View: publish state or photo callback

Reference code

Views/ContentView.swift:209 — one UI action dispatches to the service that owns the selected medium.

private func onShutterButton() {
    switch captureType {
        case .photo:
            photoCapturer.onPhotoCompletion = { image in
                showScreenFlash = true
                previewImage = image
            }
            photoCapturer.capture()
        case .video:
            toggleVideoCapture()
        case .audio:
            toggleAudioCapture()
    }
}

Naming conventions

• Owner types use role suffixes: CaptureManager, PhotoCapturer, VideoCapturer, and PreferredCameraObserver.
• Commands use concrete verbs: activate, setActive, addOutput, startRecording, stopRecording, and writeToPhotoLibrary.
• UI Boolean state uses is, can, and show; callbacks use the on...Completion form.
• +Feature filenames identify extensions of the same owner, while folders name domain responsibilities.
• Framework objects retain their Apple terminology (session, input, output, previewLayer) instead of introducing aliases.

Architecture takeaways

• Construct long-lived capture collaborators at the app boundary and pass them into SwiftUI views as observed dependencies.
• Keep one shared session owner, then give each media format a focused capture/export owner.
• Hide audio and session mutation behind commands while exposing observable state read-only where practical.
• Use small observer adapters to contain KVO and notification cleanup.
• Split a large owner by feature extensions only when ownership and invariants remain unambiguous.

Source map

• Official Apple documentation