What happens if you deny microphone permission to a dual camera app?

Audio is optional in a way video is not

A dual-camera recording is built from two video streams composited into one frame in real time — that compositing is the entire point of the app, and there is no version of it that works without both cameras. The microphone feeds a separate, single audio track that gets written alongside the video, not into it, which means an app can drop that track entirely and still produce a complete, playable file. DualCam does exactly that: when the microphone is unavailable, the audio path is skipped while the capture session is being configured, silent mode is forced on, and recording proceeds normally as a video-only file.

That is the opposite of what happens if you deny camera permission instead. Camera access has no equivalent fallback, because video is not a layer sitting on top of the app the way audio is — it is the thing being recorded. Losing the microphone costs you a track; losing the camera costs you the whole recording.

What you actually see and hear

There is no error dialog interrupting the take, and no button that stops working. The record button behaves exactly as it does with microphone access granted, the preview looks the same, and the resulting file plays back fine — it is simply silent for its entire length, the same as if silent mode had been switched on deliberately before you pressed record.

That similarity is not a coincidence. Whether the audio track is missing because permission was denied or because you turned on the app’s own mute setting, the underlying mechanism is the same: the track is either created the moment recording starts or it is not, and there is no version of the file where it gets added partway through or after the fact.

Camera and microphone are asked for, and granted, separately

iOS treats camera and microphone as two independent protected resources, each with its own authorization prompt and its own entry under Settings → Privacy & Security. Allowing one tells the system nothing about the other, so allowing the camera and denying the microphone — or the reverse — are both ordinary, supported combinations, not edge cases an app has to guess about.

The microphone prompt, like the camera one, only appears automatically the first time the app actually tries to use it. Deny it once, and the app cannot make the system ask again on its own; every iOS app that touches the microphone runs into that same wall, which exists specifically so an app cannot badger you into changing your mind.

Getting sound back without losing anything else

Microphone access lives in Settings, either under the app’s own entry or under Settings → Privacy & Security → Microphone, where it shows up alongside every other app that has asked. Turning it on there does not touch anything else about the app — your saved recordings, last-used layout and filter choice are untouched, because permission is a gate the system holds in front of the app, not a setting stored inside it.

What is worth doing afterwards is closing the app fully and reopening it, rather than switching back to it. A multi-camera capture session is typically built once, at launch, from whatever permissions are available at that moment, so a permission you just granted in Settings is the kind of change a fresh launch picks up reliably, rather than something the app is expected to notice mid-session.

If you wanted it silent anyway

Some footage is meant to be silent on purpose — b-roll, a clip you plan to score with music, anything shot somewhere too loud to bother recording. If that is the actual goal, using the app’s own mute setting is the better route: it is a deliberate choice you can turn back off for the next take, rather than something tied to a system permission you would otherwise have to revisit in Settings. Save the permission denial for when you genuinely do not want the app to have microphone access at all, on this or any recording.