Creating a Desktop Recorder That Works Across macOS Versions

Apple provides several frameworks for capturing microphone audio, application audio, and screen video on macOS. The right combination depends on which operating-system versions a desktop recorder needs to support.

On newer versions of macOS, ScreenCaptureKit can provide many of the streams needed to record a meeting. Supporting older versions is more complicated: developers may need to combine multiple APIs, synchronize their output, and maintain fallback methods for capabilities that Apple had not yet exposed.

Comparing recording approaches on macOS

A meeting recorder generally needs three media streams: the local user’s microphone, audio from remote participants, and screen capture/meeting video. No Apple API provides all three consistently across every supported macOS version.

AVFoundation

AVFoundation is Apple’s general-purpose media framework. Within it, AVAudioRecorder can save microphone input directly to a file, while AVAudioEngine provides live audio buffers for real-time transcription, voice activity detection, and other processing.

For a meeting recorder, AVAudioEngine is generally the more useful option because it gives developers control over mixing, filtering, and audio formats. However, AVFoundation does not capture outgoing audio from applications such as Zoom, Microsoft Teams, or Google Chrome. It can record the local user, but another capture method is still needed for remote participants.

ScreenCaptureKit

ScreenCaptureKit is Apple’s newer framework for capturing displays, windows, applications, and system audio. On macOS 16+, it can also capture microphone input. This makes it possible to collect screen video, system audio, and microphone audio through one framework.

Even on supported versions, ScreenCaptureKit is not a complete meeting-recording system. Its system-audio stream may include notifications, music, or other sounds playing on the computer. Window capture can also produce unexpected results when the user minimizes a meeting, enters Picture-in-Picture mode, or switches browser tabs.

ScreenCaptureKit also does not detect meetings, retrieve participant information, or produce speaker-labeled transcripts. Remote participants are mixed into one system-audio stream, so speaker separation and meeting metadata require additional infrastructure.

Core Audio process taps

Core Audio process taps provide a more targeted way to capture outgoing application audio. Instead of recording every sound produced by the computer, a recorder can tap the processes associated with a meeting application.

Developers need to identify the correct processes, create a CATapDescription, attach the tap to a HAL aggregate device, and read the resulting buffers through an audio callback. Applications and browsers might distribute audio work across several helper processes, making process selection another source of edge cases.

Process taps only address outgoing audio. A full recorder still needs AVFoundation for microphone input and ScreenCaptureKit for video. Those streams then need to be synchronized despite having different timestamps, buffer sizes, sample rates, and latency.

The problem with supporting older macOS versions

The latest Apple APIs can simplify the capture pipeline, but limiting a recorder to the newest macOS release can exclude a meaningful part of the user base. Supporting older versions means introducing fallback paths.

For example, an application might use ScreenCaptureKit for system audio and video while capturing the microphone through AVAudioEngine. On systems earlier than macOS 14.2, Core Audio process taps are unavailable, so application-specific audio capture may require a virtual audio driver or a less precise system-audio approach.

Each fallback creates another implementation to build, test, and maintain. The application must choose the correct path at runtime, guide the user through different permission flows, and normalize every path into the same output format.

Combining microphone and system audio also introduces synchronization and echo problems. Separate APIs may use different clocks, causing streams to drift during longer meetings. When users join without headphones, their microphone can pick up audio from the speakers, duplicating remote speech in the final recording.

The scope expands quickly: multiple macOS versions, Intel and Apple silicon Macs, browsers, native meeting applications, microphones, headphones, and permission states. Device switching, sleep, crashes, and connectivity interruptions introduce additional failure modes.

When Desktop Recording SDK is the more practical option

Teams can build capture paths directly using native or cross-platform APIs. However, getting a production-ready meeting recorder takes a team of at least three engineers working for six months, with ongoing maintenance continuing after launch.

For products whose value lies in summaries, CRM updates, or other workflows built on meeting data, there can be a challenge of allocating engineering resources. That is why when the capture layer is not the product’s main differentiator, a Desktop Recording SDK like Recall.ai is the more practical option. It provides an integration across macOS and Windows while automatically handling things like meeting detection, echo cancellation and device changes. It can also return recordings, metadata, and speaker-labeled transcripts.

Whichever route a team chooses, the botless recorder should be designed around capabilities rather than one macOS API. The important question is not simply whether an API can capture audio, but whether the complete system remains reliable across the operating-system versions and real-world conditions its users bring to it.