A screencast setup for developers

The Mac you write code on has been tuned for eighteen months to make you fast. Small fonts because you can read them. Three monitors because you use all of them. A browser signed into your accounts, a Dock with thirty apps, a wallpaper somebody took a photo of. Every one of those decisions is correct for work and wrong for video.

You do not need a different Mac. You need a different configuration of the same Mac that you can switch into in ten seconds and out of just as fast — because a setup that takes an hour to arrange is a setup you will skip on the day you actually want to record something. What follows builds that, in the order the decisions depend on each other.

Almost everything else on this page is a setting you would otherwise change and change back, twice, every time you record. A second macOS user account makes all of it persistent. Log in, and the desktop is already the recording desktop: its own Dock, its own wallpaper, its own menu bar extras, its own browser profile with no history and no avatar, its own editor settings with the large font.

The cost is one-time and small. You install nothing twice, because applications are shared — but each account keeps its own app settings and its own privacy grants, so plan on a short setup pass in the recording account before your first real take.

This is the decision everything visual downstream depends on, and it goes the opposite way to instinct. Your display's native resolution is close to irrelevant; what matters is the resolution the video is delivered at, because that is the scale the text has to survive.

Recording a large display and downscaling to 1080p means every glyph is being resampled — readable, but soft, and comments and low-contrast syntax colours go first. Recording closer to the delivery resolution keeps text crisp and makes the file smaller, at the cost of screen real estate you give up while recording. Apple's Displays settings let you choose a resolution directly, and Show all resolutions exposes the ones the picker hides by default.

Watch somebody else's screencast and notice how much of the frame is not the subject. The Dock. A second window's edge. A wallpaper with detail in it. A tab bar with fifteen favicons. A menu bar with a VPN indicator and a battery percentage. None of it is malicious, and all of it competes with the code.

The rule is not minimalism for its own sake — it is that anything on screen which is not the lesson will be read by somebody, and that reading is time they are not spending on the lesson.

Two things about a developer's work are invisible in a capture: what the keyboard did, and where the pointer is. Both have a fix that costs nothing at record time, and both can be overdone.

Show KeyPress draws each key press as a mechanical keycap in an always-on-top window. It is a display and nothing else — it records no video, has no plugin for any recorder or conferencing tool, and holds no network entitlement, so there is nothing to integrate and nothing leaves the Mac. Because it is drawn on the display, anything that captures the display captures it; anything scoped to one application window does not, which is the single failure mode worth remembering.

The cursor halo is the second layer, on its own toggle at ⌃⌥H, and it is the one to be sparing with. It genuinely helps when the pointer is the subject — a drag, a resize, a menu path — and it is noise the rest of the time. The animated pet is the third, and the only element that is not click-through, which is reason enough to leave it off for anything instructional.

Shift-Command-5 records the entire screen with no configuration, writes a file when you stop, and is the correct tool for most developer screencasts. It has no scenes, no camera compositing, no per-source audio and no transitions, and for a straight walkthrough it needs none of those.

OBS Studio earns its place at a specific point: when you want a camera in the corner, more than one arrangement of sources, or separate audio tracks you can fix in the edit. The important detail carries over unchanged — an OBS source that captures a display includes the overlay, and one scoped to a window or an application does not.

Audio is not a screen setting, but it is the thing viewers abandon a tutorial over faster than any visual problem, so it belongs in the setup rather than in the edit. A microphone close to your mouth in a room with soft furnishings beats an expensive one across a desk in a room with none.

The developer-specific hazard is your own keyboard. A loud mechanical board picked up by an open microphone turns every shortcut into a burst of noise underneath your voice — which is a real argument for showing the keys visually and letting the audio carry only the explanation.