Does Face ID stop dual camera recording on iPhone?

One housing, two separate imaging systems

The front camera used for a selfie, a FaceTime call, or the front half of a dual-camera recording is an ordinary visible-light camera — it captures a normal color image the same way the back cameras do, just facing the other direction. Face ID does not use that sensor at all. It reads depth and infrared reflection from a separate set of parts: a projector that casts an invisible grid of dots onto your face, an infrared camera that reads how that grid deforms across your features, and a flood illuminator that lights your face in infrared for low-light scans. None of that is color image data, and none of it is the stream a video app can even ask for.

This split predates dual-camera apps entirely — it is how every Face ID iPhone has worked since the feature was introduced, well before AVCaptureMultiCamSession made recording two ordinary cameras at once possible. DualCam’s front-camera feed and Face ID’s scan have always been two separate requests to two separate pieces of hardware; they only look related because of where Apple physically put them.

Why sharing a housing does not mean sharing a session

A capture session on iOS is granted to one app for one specific camera device at a time. DualCam’s front-camera feed is a request for the ordinary front camera device — the same one Camera app uses for a selfie. Face ID authentication is not handled through that same request path at all; it runs as its own system-level process built around the TrueDepth sensor, independent of whatever camera session any app currently has open.

That is a genuinely different situation from the one the rest of this site spends a lot of time on — two ordinary cameras, front and back, sharing one combined processing budget on the same chip. Face ID is not a third camera competing for that budget. It is a separate authentication system that happens to point in the same direction as one of the two cameras already in use.

The moments Face ID would actually come up mid-take

Starting a recording already requires the phone to be unlocked and DualCam to be the app on screen, so the ordinary reason to use Face ID — unlocking the phone — is not something a take runs into on its own. An active recording also keeps the screen awake and does not let the phone auto-lock the way it would sitting idle, so there is no routine moment where the lock screen, and Face ID with it, would appear uninvited.

The realistic case is a system prompt that happens to need a face scan for something unrelated to recording — approving a payment, or confirming a saved password an app is trying to fill in. What determines whether that interrupts the take is not Face ID itself; it is whether that prompt takes DualCam out of the foreground, the same question that decides whether any other app or system screen interrupts a recording. If it does, DualCam finalizes and saves whatever was recorded up to that point, the same handling any interruption gets. If it does not, the take simply continues once the prompt clears.

What this means in practice

For a handheld or tripod shot where you are not looking away from DualCam mid-take, this is not something to plan around at all — nothing about the shot invites a Face ID scan in the first place. It only becomes relevant on the rare take long enough, or interrupted enough by something else, that a system prompt happens to land in the middle of it, and at that point the thing worth understanding is the interruption itself, not that a face happened to be scanned along the way.