Capturing Spatial Audio in your iOS app

At a glance

Project structure

SpatialAudioDemo/
├── SpatialAudioDemoApp.swift       # Composition root
├── ContentView.swift               # Recording flow and waveform UI
├── AudioRecorder.swift             # Capture, writing, metadata, and meters
├── AudioPlayerView.swift           # Playback controls
├── AudioPlayerViewModel.swift      # AVPlayer state and observation
└── AudioVisualizerView.swift       # Small level visualization

Structure observations

• AudioRecorder is the capture boundary; it intentionally combines session setup, writer setup, delegate processing, and waveform calculation.
• Playback is a separate view/view-model pair, so capture resources do not leak into the player UI.
• There is no app-defined service protocol or repository layer.

Overall architecture

flowchart LR
    App["SpatialAudioDemoApp"] --> UI["ContentView"]
    UI --> Recorder["AudioRecorder"]
    Recorder --> Capture["AVCaptureSession + audio outputs"]
    Capture --> Writer["AVAssetWriter + metadata generator"]
    UI --> PlayerView["AudioPlayerView"]
    PlayerView --> PlayerModel["AudioPlayerViewModel"]
    PlayerModel --> Player["AVPlayer"]

Reference code

SpatialAudioDemo/ContentView.swift:14 and SpatialAudioDemo/ContentView.swift:82 — view-owned recorder

@State private var audioRecorder = AudioRecorder()

.onAppear() {
    audioRecorder.setupCaptureSession()
}

Interpretation

ContentView owns the feature lifecycle and sends user intents to AudioRecorder. The recorder is both observable app state and an AVFoundation adapter. A completed file URL is passed to the independently owned playback slice.

Ownership and state

classDiagram
    ContentView *-- AudioRecorder : creates and observes
    AudioRecorder *-- AVCaptureSession : creates
    AudioRecorder *-- AVAssetWriter : creates per recording
    AudioRecorder *-- AVCaptureAudioDataOutput : owns two
    AudioPlayerView *-- AudioPlayerViewModel : creates
    AudioPlayerViewModel *-- AVPlayer : creates on load

Ownership evidence

SpatialAudioDemo/AudioRecorder.swift:17 — private capture and writer state

private var assetWriter: AVAssetWriter?
private var session: AVCaptureSession
private var stereoAudioDataOutput: AVCaptureAudioDataOutput?
private var spatialAudioDataOutput: AVCaptureAudioDataOutput?
private var sessionQueue: DispatchQueue

Class and protocol design

SpatialAudioDemo/AudioRecorder.swift:14 — framework protocol integration

@Observable
class AudioRecorder: NSObject,
    AVCaptureAudioDataOutputSampleBufferDelegate,
    @unchecked Sendable {
    // ...
}

The sample uses AVFoundation’s delegate protocol, but defines no application protocol for interchangeable recorders or players. @unchecked Sendable is a concurrency assertion, not an access level.

Access control

Reference code

SpatialAudioDemo/AudioRecorder.swift:172 — hidden writer construction

private func setupAssetWriterWithSpatialAndStereoAudioOutput(
    _ spatialAudioOutput: AVCaptureAudioDataOutput,
    _ stereoAudioOutput: AVCaptureAudioDataOutput
) {
    // creates AVAssetWriter and its spatial, stereo, and metadata inputs
}

Logic ownership and placement

Design patterns

Naming conventions

• Types use role suffixes: View, ViewModel, and Recorder.
• Commands use verbs and expose intent: setupCaptureSession, startRecording, stopRecording, seekToAndPlay.
• Framework-backed properties name the owned object explicitly, such as assetWriterSpatialAudioInput.
• Files match their main type; the small LiveWaveformShape stays beside its only consumer in ContentView.swift.

Architecture takeaways

• Give one object exclusive ownership of a mutable capture/writer graph and its queue.
• Keep playback resources separate from capture resources even in a small demonstration app.
• Use private framework state and a small command surface to protect ordering requirements.
• This is delegate-oriented framework integration, not a broadly protocol-oriented application design.

Source map

• Official Apple documentation