What Preen does with your camera and your microphone, and what it refuses to do

Preen is a menu bar camera preview for macOS 14.0 and later, and everything it can see or touch is gated by exactly one entitlement, com.apple.security.device.camera. It never asks for microphone access, because muting your input from Preen is a Core Audio property change on your system's default microphone, not a capture of any audio. The camera light comes on only while the preview or the floating window is visible, and one method turns it off the moment both are closed.

A menu bar app that watches your camera is asking for a lot of trust. Preen sits there so you can check your framing before a call, one of several ways to do that on a Mac, and that means it has to open a live video feed on demand, on every Mac it runs on. What follows is not a features list. It is what the shipped, notarized build actually does with your camera and your microphone, read out of the source rather than off a product page.

I build Preen. Nothing below is a benchmark. There is no measured timing, no test machine, and no invented anecdote. Every claim about Preen's own behaviour comes from its shipped source or from the files it ships with, read on 23 July 2026. No competing product is named or compared here.

So what can Preen actually see and hear?

Open Preen's entitlements file and you find one line: com.apple.security.device.camera. There is no com.apple.security.device.audio-input beside it, and no App Sandbox entitlement either, because Preen ships Developer ID signed with the Hardened Runtime for direct distribution rather than through the sandboxed Mac App Store. A comment above that single entitlement explains why it stands alone: Preen's microphone mute is Core Audio device property manipulation, not capture, so it needs no audio input permission at all. macOS still re gates the camera at the Hardened Runtime level even outside the sandbox, and a build shipped without the entitlement gets killed on its first frame. That is the whole reason the entitlement exists.

One permission request, and nothing quieter behind it

Preen never asks the operating system for camera access on launch or when you first open the panel: the code path that runs on open only reads AVCaptureDevice.authorizationStatus(for: .video), a call that tells the app what the answer already is without asking anyone anything. One function in the whole app ever calls AVCaptureDevice.requestAccess, its own comment describes it as the sole permission request path, and it refuses to run unless you are already looking at Preen's own primer screen. Before the system dialog appears, Preen shows a card over a black preview: "Camera preview is private. Preen uses your camera only while this preview or the floating mirror is open. Enable it when you're ready." Only pressing Enable Camera triggers the macOS prompt, and it triggers it exactly once. Dismissing that card is remembered under one line in your defaults, and it never comes back.

The words in the actual prompt

The permission dialog macOS shows you is not boilerplate a developer forgot to change. It is a literal string, written into the app's Info.plist by the build script: "Preen shows you a live self view mirror." A microphone usage description sits in the same file, "Used only to mute your microphone," even though no code path ever triggers the prompt that string belongs to. Preen's audio behaviour later in this post is exactly why that string is never shown to you. If you have used Preen and never once seen a microphone permission dialog, that is not something slipping through: that is the design.

The light goes off exactly when you would expect, and not before

Your Mac's camera indicator is tied to whether a capture session is running, not to whether a window is visible on your screen, the same principle Submix's own audio recording indicator follows. Preen has exactly one method that decides this, refreshRunState(), and the logic inside is a single boolean: start the session if the menu bar popover is visible or the floating window is visible, stop it otherwise. Close the popover while the floating mirror stays open and the session keeps running, because the boolean is still true, and the light stays lit. That is the one case people assume should turn the camera off, and it does not. Close both windows and the same method flips to stop: the light goes dark, with no separate timer and no second path that could leave a session open after both are gone.

Muting your microphone is a property change, not a recording

Getting this part wrong would cost Preen its whole reputation as a camera app. Muting your microphone from Preen does not open an audio stream, does not create an audio unit, and never touches AVCaptureDevice for audio at all. It resolves your system's current default input device through kAudioHardwarePropertyDefaultInputDevice, checks whether that device exposes a settable kAudioDevicePropertyMute, and either flips that property directly or, on a device that does not support it, saves the current kAudioDevicePropertyVolumeScalar and writes zero in its place. Both operations sit at kAudioDevicePropertyScopeInput, on the input side of one device object, nowhere near a microphone buffer. Nothing is captured, nothing is buffered, and nothing leaves the device object it started at.

Your meeting app still thinks you're unmuted

A device property change is invisible to any software that already opened its own audio session against that microphone. Zoom, Teams, and every other conferencing app reads its mute state from its own toggle, not from Core Audio's mute flag on shared hardware, so flipping the system property does not move a switch inside a call already running. Preen admits this on the first mute rather than letting you discover it live: "Your meeting app may still show you unmuted." That sentence is not buried in a settings pane. It is the first thing the app tells you.

A file gets written before your volume does

Before zeroing an input's volume, Preen saves the device ID, the method used, and the exact pre mute volume to a file in Application Support, using a temporary file, an explicit filesystem sync, and an atomic rename, then reads that file back and checks it matches before touching your hardware. If that write, sync, or read back fails, the mute does not happen at all. Every mute and unmute afterward is verified the same way: Preen reads the property it just set and compares it against what it meant to write, and if the two disagree, it leaves your recorded state untouched rather than reporting a mute that did not take.

What happens if Preen just dies

If Preen is force quit, loses power, or crashes mid session, the recovery file survives, because it was written and synced before any hardware write happened. The next launch reads that file, restores the muted device to its saved volume or clears the mute property, verifies the restore the same way it verifies everything else, and only then deletes the file. When the restore cannot be verified, Preen does not pretend it worked. It says plainly that microphone recovery needs attention and asks you to reconnect the previous input and reopen the app.

No license check blocks the unmute button

The function that restores your system audio runs before the app checks whether your trial or license is even valid, a choice that runs against the obvious business incentive, and the comment beside that call spells out why: restoring system audio must always remain possible. If your trial expires while your microphone is muted, or a license check fails for any reason, you are never left stuck with it. The mute button is disabled only while you are already muted, never while unmuting is the thing you need.

Three things Preen admits it cannot do

The honest version of this post has to include what does not work.

Preen's mute reaches exactly one device, whichever one macOS currently calls the default input. If your conferencing app is set to a different microphone than your system default, muting through Preen changes nothing that app hears, because Preen never looked at that other device at all.

Preen also does not watch for the default input changing while a mute is active. Switch inputs mid mute and the device Preen originally muted stays muted and mostly forgotten, while Preen's own status line keeps showing the state it set rather than what your Mac just switched to. And on the handful of microphones that expose neither a settable mute property nor an adjustable input volume, Preen cannot mute at all, and says so in plain text rather than pretending to succeed. None of these three are waiting on a fix here. They are here because a page that lists only what an app does to your camera and microphone, never what it fails to do, is not a page anyone should trust.

Questions people ask

Does Preen ever record or store video or audio?

No. The capture session feeds a live preview layer and, only when you press the shutter, a still image saved as a PNG in your Pictures folder. No continuous recording path exists in the shipped build, and no audio path exists beyond the Core Audio property calls described above.

Does the green light mean Preen is watching me?

It means a capture session is running, which for Preen means the popover or the floating window is open. Preen never locks the camera for itself, but macOS still only delivers a live feed to one app at a time: if another app already holds the same camera, Preen's own session gets nothing until that app lets go of it.

Why doesn't the mic mute affect the microphone icon in my meeting app?

Because Preen changes a Core Audio device property on your system's default input, and your meeting app reads its own separate mute state from its own toggle. Preen tells you this on the first mute rather than letting you find out mid call.

Does unmuting require a license?

No. The restore function runs before any license or trial check, on purpose, because leaving someone's microphone silently muted was judged the worse failure.

Is Preen sandboxed, or on the Mac App Store?

No. It ships Developer ID signed with the Hardened Runtime, distributed as a direct download for macOS 14.0 and later, with one camera entitlement and no App Sandbox entitlement.

See the rest of what shipped in the current build on the Preen page, or read more of what the source says in the Preen notes.