The First Layer: Capturing Evidence Across Platforms
For Recordly, capture is not a single operation that produces a video file and ends. It is the platform-aware process that decides which screen or window can be observed, which audio sources can be synchronized, whether the real cursor can be excluded, and what interaction evidence the editor will later use. Understanding this layer lets readers predict what Recordly can polish after recording—and what a fallback or permission boundary may make impossible.
Why Recordly needs more than one capture route
A screen recorder sits between an application and an operating system that controls access to displays, windows, audio devices, cursors, and permissions. Those controls are not uniform. The most reliable way to capture a selected window on one platform may not exist on another, and an API that returns a video stream may not provide the timing or cursor behavior needed for a polished editor.
Recordly therefore routes capture according to both platform and source. On macOS, its native path uses ScreenCaptureKit and AVFoundation. On supported Windows systems, a native helper uses Windows Graphics Capture with a D3D11 device and Media Foundation encoding. Browser-oriented Electron capture remains important: it is the primary route for Linux in the documented workflow and a fallback when Windows native capture is unavailable. The main process owns the native helper processes and their output files; the renderer asks for a recording and responds to the result.
That division of ownership matters. The renderer knows the user-facing choices: screen or window, microphone, system audio, webcam, countdown, pause, and stop. The main process can inspect the operating system, spawn a helper, hold its process state, validate its output, and expose a safe path back to the editor. A native helper can perform work close to the operating system without giving the renderer unrestricted control over local files or devices.
The preferred route is conditional even before the first frame arrives. Recordly documents macOS 14.0 and later, and its Windows availability check requires Windows 10 build 19041 or later plus a usable native helper. A Windows installation that does not meet those conditions can still attempt browser capture. On macOS, the application must obtain Screen Recording permission and may need Accessibility permission for cursor tracking. Microphone permission is a separate condition. Linux capture may depend on the desktop portal and, for system audio, usually on PipeWire.
This is why “supports screen recording” is too broad a description to guide a real user. The relevant question is: which capture contract is active on this machine? A native route may provide better control over the operating-system cursor and window cropping. A browser route may be more widely available but can inherit Chromium or desktop-compositor behavior. Recordly's editor has to accept both kinds of source while preserving enough information for later stages to make a sensible result.
The native paths are also different in what they capture before the editor sees anything. The macOS helper configures a ScreenCaptureKit stream, disables the real cursor, and uses a display filter even when the user selected a window. For a window, it calculates the visible region within the display and crops the frames before writing them. This matters when a window moves or spans a display: the helper is not simply asking the browser to hand back a rectangle whose coordinate system may be ambiguous. It is making the crop explicit at the capture boundary.
The Windows helper takes a related but distinct route. Windows Graphics Capture supplies D3D11 textures through a frame pool. The helper disables cursor capture, maps desktop coordinates into capture-surface pixels, and crops a selected window from the monitor texture. It also has to account for DPI differences and for a window changing size. If the source dimensions change, the frame pool may need to be recreated; if the encoder's dimensions are fixed, the crop must be kept compatible with the file being written. These are concrete reasons a “window recording” feature cannot be reduced to one platform-neutral function.
Browser capture has a different ownership model. The renderer requests a display stream through Electron's configured media handler, receives a video track, and may request system audio or a separate microphone stream. On Linux with a desktop portal, Recordly uses a sentinel route to avoid triggering redundant source-selection dialogs. If a requested system-audio stream cannot be obtained, the browser path can continue with video rather than pretending that silent audio is present. The result is more variable, but it keeps the application usable on systems where native helpers are unavailable.
The sequence has two important consequences. First, the native helper and browser stream are alternative capture mechanisms, not two copies of the same implementation. Second, recording is not complete merely because a stop button was pressed. The output must be finalized, checked, and associated with the evidence that the editor will need.
What capture preserves besides pixels
The source video is the obvious artifact, but Recordly also builds a time-indexed record of interaction. During recording, the main process samples cursor points and interaction types such as clicks. Those samples are normalized to positions and associated with timestamps. The editor can later interpolate between samples, identify a click, choose a cursor type, and apply smoothing or a visual effect without changing the original screen pixels.
This separation is the basis of Recordly's cursor polish. A rendered cursor is not necessarily the real operating-system cursor that appeared during capture. On native macOS and Windows routes, the helper can exclude the real cursor from the captured image. Recordly can then draw a styled cursor during preview and export. On a browser fallback, cursor behavior depends on the capture policy and platform. Linux is an explicit boundary: Electron desktop capture does not currently support hiding the real cursor, so a recording can contain both the real cursor and a rendered one if the overlay is enabled.
The same principle applies to audio, although audio timing is less forgiving than cursor styling. Native macOS capture can write inline audio and separate companion tracks. Windows native capture can produce system-audio and microphone WAV sidecars, with timing metadata. If native microphone capture cannot initialize—or if the route explicitly delegates the microphone to the browser—the renderer can record a microphone sidecar through getUserMedia and MediaRecorder, then pass it to the main process for conversion and storage. The main video can therefore survive even when one requested track does not.
The distinction between an inline track and a companion track is useful here. An inline track travels inside the captured video container. A companion track is a separate file associated with the recording and discovered by the editor. Keeping audio separate can avoid an expensive post-recording mux at capture time and can preserve diagnostics about start delay, discontinuities, or the browser recorder that produced the sidecar. It also means that the editor must resolve several related paths as one recording session rather than treating the MP4 as a complete, self-describing package.
Recordly uses a common time base to keep these streams meaningful. On macOS, audio timestamps are made relative to the first video sample, and paused duration is removed from the effective timeline. On Windows, the native helper uses high-resolution timing for video and WASAPI packets, records a microphone or system-audio start delay, and tracks discontinuities. Larger gaps may be filled with silence; short discontinuities can be compacted rather than turned into unnecessary audible gaps. These are not cosmetic details. If audio starts late or a pause is counted differently in different tracks, the editor cannot reliably align the pieces later.
Pause and resume therefore affect more than the button state. A native helper may stop accepting samples while paused, then adjust timestamps when capture resumes. The renderer also tracks pause boundaries for browser microphone and webcam recordings. The intended result is an effective recording timeline without the wall-clock interval in which the user deliberately paused. That same boundary information later influences trimming, playback speed, cursor motion, and export duration.
The cursor has a related boundary. Recordly's cursor telemetry is not a guarantee that every pointer event was sampled at the same rate as the video. It is a time-indexed observation that the renderer interpolates and smooths later. That is powerful because it allows presentation changes, but it also means that the polished cursor is a reconstruction. A missing sample, an abrupt time jump, or a source crop can change what the renderer can safely infer. The system preserves evidence for editing; it does not turn an imperfect capture into a perfect measurement of every physical pointer movement.
Window capture creates another kind of evidence problem. A selected window can move between displays, resize, disappear, or become un-capturable. The native macOS helper periodically validates a selected window and can stop if it is no longer available. The Windows path monitors its helper lifecycle and reports an unexpected stop. Recordly can recover a file that was already written, prompt the user to reselect a missing window, or reject an output that fails video validation. The goal is not to pretend capture cannot fail; it is to avoid handing the editor a path that looks successful but contains an unusable file.
Why fallbacks are part of the user experience
A fallback is often described as a technical safety net, but in Recordly it can change the evidence available to every later stage. If native Windows capture fails before it starts, the application falls back to browser capture and changes its cursor policy so that the browser-captured cursor can remain visible instead of relying on a delayed telemetry overlay. If native microphone capture is unavailable, a browser microphone may be recorded separately with its own start delay and chunk timing. If a renderer or encoder lacks a required capability, a different output route may be selected.
The right way to evaluate such behavior is not to ask whether the fallback is identical. It usually is not. Ask instead what property the fallback preserves. Browser capture may preserve the main screen video while losing native cursor exclusion. A microphone sidecar may preserve speech while requiring later synchronization. Recovery may preserve a valid main video while leaving out a webcam or audio companion. A diagnostic record can preserve the explanation of what happened even when it cannot restore the missing media.
This also explains why Recordly asks for permissions at the point where they matter. On macOS, the application checks screen-recording and Accessibility status rather than silently starting a partial session. On Windows and Linux, the available APIs and desktop environment determine which permission or portal flow can run. The main process restricts display and media permissions to trusted capture contexts and does not grant unrelated device permissions by default. Permission handling is therefore part of the capture contract, not a preface that can be ignored once the window opens.
The stop path reflects the same discipline. Native capture sends a stop command to the helper and waits for a reported output path. The main process validates the file before publishing it as the current video. Cursor telemetry is persisted before the editor needs it, while webcam finalization, microphone sidecars, and Windows audio handling can continue in the background. This lets the editor open promptly without confusing an early main-video handoff with completion of every companion asset.
If finalization fails, Recordly can inspect a preferred output path or a temporary path and try recovery. If no valid video remains, it reports failure rather than opening an editor around a broken file. If the selected window vanished, the renderer can receive an interruption and ask for a new source. The details differ across helpers, but the ownership rule stays stable: the capture boundary decides whether a usable artifact exists; the editor should not be forced to guess.
The practical boundary is clear. Recordly can preserve interaction evidence only if it can observe the interaction or capture a usable substitute. It can align audio only if the relevant track exists and timing can be measured. It can hide the real cursor only where the active capture route and operating system support that behavior. When those conditions fail, the application can degrade, recover, or stop—but it cannot reconstruct evidence that never crossed the capture boundary.
That boundary is what makes the next layer necessary. Once Recordly has a video, cursor samples, audio tracks, and perhaps a webcam file, it still has only evidence of what happened. A polished result requires the editor to turn those inputs into a stable visual scene: one that knows when to zoom, how to smooth a cursor, where to place a webcam, and which layers should appear at each timestamp. Capture supplies the material; the renderer supplies the presentation.