Building a responsive camera app that launches quickly

At a glance

Platform boundary: the DocC record lists iOS, iPadOS, and Mac Catalyst. In the downloaded project, every target sets SUPPORTS_MACCATALYST = NO with SDKROOT = iphoneos (AVCam.xcodeproj/project.pbxproj:945), and the deployment target is iOS 26.0 (AVCam.xcodeproj/project.pbxproj:936), while the DocC record lists 27.0. The bundled README.md is the generic AVCam overview (README.md:1), so this analysis relies on the source code and its comments for the launch-specific behavior.

Project structure

AVCam.xcodeproj/                     (3 targets, no Swift packages)
AVCam/                               app sources (also compiled into the capture extension)
├── AVCamApp.swift                   @main App; .task { await camera.start() }
├── CameraModel.swift                @MainActor @Observable; sets status = .running
├── CaptureService.swift             actor; deferred-start configuration in setUpSession()
├── Capture/
│   ├── PhotoCapture.swift           enables responsive capture on the photo output
│   └── MovieCapture.swift           configures the video connection before recording
├── Model/                           Camera protocol, CameraState, DataTypes, MediaLibrary actor
├── Support/ViewExtensions.swift     View.hidden(until:)
└── Views/
    ├── PreviewContainer.swift       background cover keyed to scenePhase
    ├── CameraUI.swift               window size from onGeometryChange
    ├── Controls/CaptureModeView.swift
    └── Toolbars/                    MainToolbar, FeatureToolbar, CaptureButton
AVCamCaptureExtension/               LockedCameraCaptureExtension entry
AVCamControlCenterExtension/         ControlWidget bundle

Structure observations

• The project has three native targets: AVCam (application), AVCamCaptureExtension (ExtensionKit extension), and AVCamControlCenterExtension (app extension) (AVCam.xcodeproj/project.pbxproj:445). The capture extension compiles the shared AVCam sources, including CaptureService.swift and CameraModel.swift (AVCam.xcodeproj/project.pbxproj:525, AVCam.xcodeproj/project.pbxproj:542). It creates its own CameraModel and starts it the same way the app does (AVCamCaptureExtension/AVCamCaptureExtension.swift:17, AVCamCaptureExtension/AVCamCaptureExtension.swift:25).
• The launch work splits into two layers that never call each other directly. The capture layer (CaptureService.setUpSession()) opts outputs into deferred start. The view layer gates controls on camera.status == .running. The only link between them is CameraModel.status.
• The deferral is implemented once, as a View extension (AVCam/Support/ViewExtensions.swift:64), and applied by the views that should wait (AVCam/Views/Toolbars/MainToolbar/MainToolbar.swift:25, AVCam/Views/Controls/CaptureModeView.swift:44, AVCam/Views/Toolbars/FeatureToolbar/FeatureToolbar.swift:36).
• The project still includes the AVCam rotation coordinator, which setUpSession() creates after it adds the outputs (AVCam/CaptureService.swift:158).

Overall architecture

flowchart LR
    App["AVCamApp .task"] --> Model["CameraModel (@MainActor, status)"]
    Model --> Service["CaptureService actor (sessionQueue executor)"]
    Service --> Session["AVCaptureSession (automaticallyRunsDeferredStart)"]
    Service --> Outputs["Photo / movie outputs (isDeferredStartEnabled)"]
    Service -. "nonisolated previewSource" .-> Preview["CameraPreview / PreviewView"]
    Model --> Gate["hidden(until: status == .running)"]
    Gate --> Controls["Thumbnail, switch camera, mode picker, feature toolbar"]
    Model --> Shutter["CaptureButton (always visible)"]

Reference code

AVCam/CaptureService.swift:137 — deferred-start configuration in setUpSession()

    private func setUpSession() throws {
        // ...
        do {
            // ...
            // Deferred start brings up the preview first, and prepares the capture outputs a moment
            // later. An app that links the iOS 26 SDK gets this behavior by default; these
            // assignments show the properties that control it.
            captureSession.automaticallyRunsDeferredStart = true

            // Add the photo capture output as the default output type.
            photoCapture.output.isDeferredStartEnabled = photoCapture.output.isDeferredStartSupported
            try addOutput(photoCapture.output)
            // If the capture mode is set to `video`, add a movie capture output.
            if captureMode == .video {
                // Add the movie output as the default output type.
                movieCapture.output.isDeferredStartEnabled = movieCapture.output.isDeferredStartSupported
                try addOutput(movieCapture.output)
                setHDRVideoEnabled(isHDRVideoEnabled)
            }
            // ...
        } catch {
            throw CameraError.setupFailed
        }
    }

Interpretation

Observed: the sample uses the automatic mode. It sets automaticallyRunsDeferredStart = true and enables isDeferredStartEnabled on each output only when isDeferredStartSupported is true. The source does not call runDeferredStartWhenNeeded or set a deferred-start delegate, so there is no manual trigger to analyze. The source comment notes that these assignments match the default for an app that links the iOS 26 SDK. They make the opt-in visible rather than changing behavior.

Inference: the architecture needs very little extra structure for fast launch because AVCam already isolates session work in an actor with its own queue. The launch-specific edits add configuration flags in the actor and a visibility rule in the views.

Ownership and state

classDiagram
    AVCamApp *-- CameraModel : @State camera
    AVCamCaptureExtension *-- CameraModel : @State camera
    CameraModel *-- CaptureService : private let
    CameraModel *-- MediaLibrary : private let
    CaptureService *-- AVCaptureSession : private let
    CaptureService *-- PhotoCapture : private let
    CaptureService *-- MovieCapture : private let
    MainToolbar o-- CameraModel : reads status
    PreviewContainer *-- CoverState : @State coverOpacity
    CameraUI *-- WindowSize : @State windowSize

Ownership evidence

AVCam/CameraModel.swift:68 — the single writer of the launch gate

    func start() async {
        // Verify that the person authorizes the app to use device cameras and microphones.
        guard await captureService.isAuthorized else {
            status = .unauthorized
            return
        }
        do {
            // Synchronize the state of the model with the persistent state.
            await syncState()
            // Start the capture service to start the flow of data.
            try await captureService.start(with: cameraState)
            observeState()
            status = .running
        } catch {
            logger.error("Failed to start capture service. \(error)")
            status = .failed
        }
    }

Observed: launch readiness is not a separate flag. Views reuse the existing CameraStatus value, and StatusOverlayView already renders the unauthorized, failed, and interrupted cases (AVCam/Views/Overlays/StatusOverlayView.swift:14). Controls stay at zero opacity in every state except .running.

Concurrency, scheduling, and thread safety

Evidence limit: actor isolation, async/await, or Task creation does not by itself prove background-thread execution; Sendable conformance alone does not prove thread-safe mutation.

Reference code

AVCam/CaptureService.swift:99 — session start on the actor’s queue

    func start(with state: CameraState) async throws {
        // Set initial operating state.
        captureMode = state.captureMode
        isHDRVideoEnabled = state.isVideoHDREnabled
        
        // Exit early if not authorized or the session is already running.
        guard await isAuthorized, !captureSession.isRunning else { return }
        // Configure the session and start it.
        try setUpSession()
        captureSession.startRunning()
    }

Interpretation: the README explains that configuring and starting a session are blocking operations, and that the actor keeps them off the main thread (README.md:13). The custom executor (AVCam/CaptureService.swift:71) is the code that makes this true. While startRunning() blocks sessionQueue, CameraModel.start() is suspended at await, so the main actor can keep rendering the preview container and the visible shutter. Deferred start then shortens the blocking call itself by postponing output preparation (per the source comment at AVCam/CaptureService.swift:137).

Not established by source: how long deferred start takes, or exactly when outputs become ready. The app has no deferred-start callback and does not observe readiness. Its only signal is CameraModel.status, which becomes .running once startRunning() returns.

State propagation, frameworks, and dependencies

Evidence limit: an import proves a source-level compilation dependency at the cited line; it does not prove runtime use, architectural adoption, or whether a Swift package is a direct application dependency.

Combine scheduling: the source never calls receive(on:) or subscribe(on:). Delivery to the model goes through .values inside main-actor tasks.

Class and protocol design

classDiagram
    class Camera {
        <<protocol>>
        status
    }
    class OutputService {
        <<protocol>>
        updateConfiguration(device)
    }
    class PreviewSource {
        <<protocol>>
    }
    CameraModel ..|> Camera
    PreviewCameraModel ..|> Camera
    PhotoCapture ..|> OutputService
    MovieCapture ..|> OutputService
    DefaultPreviewSource ..|> PreviewSource
    MainToolbar --> Camera : generic, reads status
    CaptureService --> OutputService : updateConfiguration

Reference code

AVCam/Capture/MovieCapture.swift:100 — connection setup moved out of the record path

    func updateConfiguration(for device: AVCaptureDevice) {
        // The app supports HDR video capture if the active format supports it.
        isHDRSupported = device.activeFormat10BitVariant != nil

        // The output has a video connection only while the session contains it, which is the
        // case in video capture mode. Adding the output creates a new connection, so the service
        // configures it here rather than when recording starts.
        guard let connection = movieOutput.connection(with: .video) else { return }

        // Configure the connection for HEVC capture.
        if movieOutput.availableVideoCodecTypes.contains(.hevc) {
            movieOutput.setOutputSettings([AVVideoCodecKey: AVVideoCodecType.hevc], for: connection)
        }
        // ...
        if connection.isVideoStabilizationSupported {
            connection.preferredVideoStabilizationMode = .auto
        }
    }

Observed: OutputService.updateConfiguration(for:) is the hook CaptureService calls for every output whenever the configuration changes (AVCam/CaptureService.swift:527). This tree uses that hook to move HEVC and stabilization setup ahead of recording. The source comment gives the reason: it avoids “changing the framing at the moment recording begins” (AVCam/Capture/MovieCapture.swift:116).

Access control

Reference code

AVCam/Support/ViewExtensions.swift:59 — the shared deferral modifier

extension View {
    /// Hides this view until the capture session is running.
    ///
    /// The app applies this to its controls so that it doesn't show UI until it's
    /// functional, and so the preview is the first thing to appear at launch.
    func hidden(until isRunning: Bool) -> some View {
        opacity(isRunning ? 1 : 0)
            .animation(.easeIn(duration: 0.3), value: isRunning)
    }
}

Observed: the modifier uses opacity rather than conditional inclusion, so the hidden controls stay in the view hierarchy and keep their layout space before launch completes. Most declarations use Swift’s implicit internal. The private and private(set) modifiers above are the meaningful boundaries.

Logic ownership and placement

Design patterns

Removed from the draft: “Service object”, which came from the Service suffix and adds nothing beyond the verified actor and protocol boundaries, and “SwiftUI environment injection”. The views read system environment values (scenePhase, size classes), but the app does not inject its own dependencies through the environment: CameraModel is passed as an initializer argument (AVCam/AVCamApp.swift:23). No MVVM or Coordinator label is claimed.

Main application flow

sequenceDiagram
    participant View as CameraView .task
    participant Model as CameraModel (MainActor)
    participant Service as CaptureService (sessionQueue)
    participant Session as AVCaptureSession
    participant Controls as Gated controls
    View->>Model: await start()
    Model->>Service: await isAuthorized
    Model->>Model: await syncState()
    Model->>Service: await start(with:)
    Service->>Session: deferred-start flags, add outputs
    Service->>Session: startRunning()
    Service-->>Model: return
    Model->>Model: observeState(); status = .running
    Model-->>Controls: hidden(until:) fades in

Reference code

AVCam/Views/Toolbars/MainToolbar/MainToolbar.swift:19 — gated controls around an ungated shutter

    var body: some View {
        HStack {
            ThumbnailButton(camera: camera)
                // Hide the thumbnail button when a person interacts with capture controls.
                .opacity(camera.prefersMinimizedUI ? 0 : 1)
                // Hide it until the capture session runs, using a custom modifier.
                .hidden(until: camera.status == .running)
            Spacer()
            // The capture button stays visible. A capture that arrives before deferred start
            // finishes is still honored, because the photo output enables responsive capture.
            CaptureButton(camera: camera)
            Spacer()
            SwitchCameraButton(camera: camera)
                // Hide the camera selection when a person interacts with capture controls.
                .opacity(camera.prefersMinimizedUI ? 0 : 1)
                // Hide it until the capture session runs, using a custom modifier.
                .hidden(until: camera.status == .running)
        }
        // ...
    }

Observed: the order in the diagram comes from CameraModel.start() and CaptureService.start(with:), which are excerpted in full under Ownership evidence and in the concurrency section’s reference code. Inference: since syncState() awaits the capture intent’s stored context before the session starts, that fetch is on the launch path. A team optimizing launch further could measure it, but the source makes no claim about its cost.

Naming conventions

• Types: the same AVCam role nouns as the base sample: CaptureService (actor), CameraModel, PhotoCapture/MovieCapture output wrappers, AVFoundation adopters ending in Delegate, PreviewContainer, CameraUI, toolbar and button views.
• Protocols: Camera for the view-facing capability. OutputService, PreviewSource, and PreviewTarget for collaborator roles.
• Methods: the launch addition reads as a sentence at the call site: .hidden(until: camera.status == .running). Lifecycle verbs are start, setUpSession, syncState, observeState, and updateConfiguration(for:). View handlers follow update<Thing>(_:_:), matching the onChange signature (updateBlurRadius, updateCoverOpacity). The AVFoundation flags use framework names (isDeferredStartEnabled, automaticallyRunsDeferredStart). App Booleans use is…/prefers…/should….
• Files and extensions: one primary type per file. The generic modifier is in Support/ViewExtensions.swift, not in a launch-specific file, so launch behavior appears as edits to existing types rather than a new module.

Architecture takeaways

• Fast launch here is two independent mechanisms joined by one value. The capture actor defers output preparation, the views defer noncritical controls, and CameraModel.status is the only signal between them.
• The actor’s custom serial executor is what keeps the blocking startRunning() off the main actor (AVCam/CaptureService.swift:71). Deferred start shortens that call but does not remove the need for the actor.
• Hide with opacity, not conditional view creation, when layout must stay stable. Keep the primary action (the shutter) available and rely on a framework capability (responsive capture) to accept early input.
• Move expensive or framing-changing setup from the action path to the configuration path. MovieCapture.updateConfiguration prepares the video connection before the person presses record.
• Task lifetimes are mostly implicit. The start-up task belongs to SwiftUI’s .task, the observation loops are unretained, and only subjectAreaChangeTask is stored and cancelled.

Source map

• Official Apple documentation