The camera session for the Duo told you the shape of the change — two front cameras, one per display, and a device you can open, close and turn around mid-capture. The two articles Apple published this month fill in the API: direction is now something you ask for, not something you infer.
Confirmed Apple's documentation states it. Each claim links to the source article.
Our reading What it means for your code. Not Apple's words.
Open Apple has not answered it, so we have not guessed.
01 · The problem
On an iPhone with one display, a camera's direction is a fixed property of the device: the front camera faces the same way as the display, the rear cameras face the opposite way. Apple's framing of the Duo case:
Why position stops being enough
"iPhone Duo has a display on each side and a camera above each one, so which way a camera faces depends on the display your app appears on. Opening or closing the device moves your app to the other display, and a camera that faced the same way as your interface now faces the opposite way."
The article then draws the line precisely: position still reports where a camera sits, and on the Duo the new coordinator reports which way it faces. A rear camera can be the forward-facing one — that is how someone takes a selfie with it.
02 · Option 1: keep capturing from the virtual front camera
If your app only ever needed a front camera, Apple's recommendation is that you change nothing. Discover cameras the way you already do, with a DiscoverySession that specifies your device types and the front position:
| Device types that return the virtual front camera | What it does on the Duo |
|---|---|
.builtInWideAngleCamera and .builtInUltraWideCamera, position .front | Streams from the camera above the display your app appears on, and follows your app as someone opens and closes the device |
- It is a virtual device:
isVirtualDeviceistrue, so code that already handles the dual camera handles this one too. - Ask which physical camera is streaming:
activePrimaryConstituentreturns it —niluntil the session runs. - Capabilities are the intersection: what both cameras have in common. The system decides which one streams.
Our reading: this is the quiet good news in the whole change. A video-call or QR-scanning app that discovered .front keeps working, and the switch happens under it. What you give up is per-camera capability — if you wanted the outer ultra-wide specifically, you are now in the next section.
03 · Option 2: the physical cameras and the direction coordinator
When capture is your app's main job, take the two physical cameras — .builtInOuterUltraWideCamera and .builtInInnerUltraWideCamera — and let AVCaptureDeviceDirectionCoordinator tell you which one is usable. Apple's article describes it as a coordinator that takes the view showing your preview as its frame of reference, groups the cameras you capture from into forward-facing and backward-facing, and calls your handler whenever that grouping changes.
| Rule from the article | Why it matters |
|---|---|
| Create it on the main actor, with the preview view, your device types and a change handler | The handler is called on the main actor, soon after you create it and again on every change |
| List every built-in camera you capture from — including your rear cameras | A rear camera can face forward on the Duo, and the coordinator reports only the built-in types you list |
| List the two physical front cameras in place of the virtual one | The coordinator leaves the virtual front camera out, because the system already moves it for you |
| Listing an external camera, Continuity Camera or Desk View camera has no effect | They are not part of this map |
| One coordinator per preview view, held strongly for as long as that view is onscreen | A coordinator reports directions relative to one view; show previews on both displays and you need two — the same rear camera comes back forward from one and backward from the other |
What the handler hands you
An AVCaptureDeviceDirectionMap with forwardFacingDeviceDescriptors and backwardFacingDeviceDescriptors. Until the first call arrives, deviceDirections returns an empty map. Compare the camera you are capturing from against the forward-facing array rather than assuming it still faces the right way, and choose a replacement when it drops out.
Descriptors (AVCaptureDeviceDescriptor) and maps are Sendable: read the map on the main actor, resolve the descriptor with AVCaptureDevice(uniqueID:) on the actor that owns your capture session. A descriptor identifies a camera but does not reserve one, so handle the case where it resolves to nothing rather than force-unwrapping.
Apple's own advice on the switch itself: reconfigure a single video input rather than connecting both cameras in a multicam session — it costs less and covers what most apps need.
AVCaptureDeviceDirectionCoordinator, AVCaptureDeviceDirectionMap, AVCaptureDeviceDescriptor and SwiftUI's CameraCaptureAccessory as iOS 27.1 — beta (Mac Catalyst 27.1 for the AVKit types). We read that straight from Apple's own documentation data, so code using them should be gated behind an availability check if you also ship to earlier systems.04 · Mirroring and rotation
Two details in the article are the kind that cost an afternoon if you meet them in a bug report instead of in the docs.
Mirror from the map, not from the position
A capture connection mirrors the preview of any camera whose position is .front — that describes where the camera sits, not where it points. So on the Duo you have to take over mirroring yourself whenever the two disagree: a rear camera facing forward should be mirrored (the person expects a selfie image), a front camera facing backward should not be.
- Guard on
isVideoMirroringSupportedfirst. - Set
automaticallyAdjustsVideoMirroring = falsebefore assigningisVideoMirrored— assigning while the connection adjusts mirroring itself raises an exception. - Re-apply after you connect a new device: removing and adding an input creates a preview connection that does not carry your override.
Rotation still applies, and the angle moves with the display
AVCaptureDevice.RotationCoordinator reports how much to rotate preview and captured output to keep them horizon-level relative to gravity. On the Duo the angle also changes as your app moves between displays, and a rotation coordinator reports for the device you created it with — so create a new one each time you switch cameras.
Our reading: note the shape of Apple's answer to "does this break my app?" — the same code runs on every iPhone. On a single-display device the coordinator reports the cameras you already expect, front in the forward array and rear in the backward one, and your handler gets exactly one call. The argument for adopting it is not the Duo alone; it is that direction becomes the thing you ask about instead of inferring it from a type or a position.
05 · The script on the outer display
The second article is about a genuinely new surface. Apple's example is a person recording someone else reading from a script: the person holding the device sees the capture interface, the person in front of the camera sees nothing — and on the Duo the outer display faces the same way as the camera. So the app declares that content as a scene accessory attached to the view showing the capture interface, and the system decides when and where to present it.
| Where you are | What you call |
|---|---|
| SwiftUI | Add the sceneAccessory(content:) modifier to the capture view and declare a CameraCaptureAccessory inside it |
| UIKit | Create one with UISceneAccessory.cameraCapture(sceneConfiguration:userInfo:) and pass it to registerSceneAccessory(_:) on the view controller showing your capture interface |
| Both | Hold a strong reference to the UISceneAccessoryRegistration that registering returns — it reports availability and carries the off switch |
- Scoped to one view: the system presents your content only while the capture interface is onscreen, and stops when someone navigates away.
- No scene manifest entry: unlike ordinary window scenes, accessory scenes have no project-level configuration, so one has no effect. Your app never sets the session role — compare it against
UISceneSession.Role.windowCameraCaptureAccessoryif your delegate handles several kinds of scene. - State travels as an object: pass the model your capture interface already uses as the accessory's
userInfoand read it back fromconnectionOptions.sceneAccessoryUserInfo. A control tapped on the outer display then changes what the person holding the device sees, with no message passing. - Touch is real, scope is not: the outer display accepts touch, which suits a single capture task like tapping the preview to focus — not a second interface. Keep every essential control in the capture interface.
Our reading: read the design guidance as the load-bearing part, not the API. Apple repeats that accessory content is an enhancement the system can withdraw at any time: design the capture interface to work when no outer display exists and when the system presents nothing there. If your teleprompter feature only works when the accessory is up, it is not a feature — it is a dependency the system can take away mid-take.
06 · What the system decides — and what you decide
Availability and on/off are deliberately separate things in this API, and the article is explicit that only the system sets availability.
| Event or control | Behaviour |
|---|---|
| Availability drops | Content goes away when capture stops, when your app leaves the foreground, or when someone folds the device closed — and while unavailable, the registration stays inactive and availability stays false |
| You turn it off | Your app's decision, not the system's: a binding on CameraCaptureAccessory(isEnabled:) in SwiftUI, or registration.isEnabled in UIKit. Turning it off dismisses the content; accessory content is on by default |
| Two registrations of the same kind | The system presents the top-most one. Navigating to a view that registers its own content makes the previous one unavailable; going back restores it |
| Two registrations of different kinds | They never compete — an app can show slides on a connected display and capture content on the outer display at the same time |
| Testing | Build the content from ordinary views so previews and Simulator can check its layout — but Simulator has no camera, so test anything depending on capture on a device. The system presents only when the device is open, the app is foreground and a capture session is running |
Our reading: the Group Lab answer on animation rates wraps around the same rule — accessory presentation is system-controlled, so design animations that can start, pause and stop cleanly at any point, and reach for TimelineView or CADisplayLink if your content needs custom timing. Apple also confirmed in the same Q&A that capture previews and AlarmKit are the two ways an app gets content onto the outer display in a standing pose.
07 · What this means for your app
- Nothing to do if you never capture. Camera direction is a problem only for apps with a capture session — the rest of the Duo work is layout, which the readiness checklist covers.
- Minimal path: keep discovering
.front, keep the virtual front camera, and the system moves between the two physical cameras for you. - Real camera apps: physical device types plus a direction coordinator, mirroring driven by the map, and a rotation coordinator per camera switch.
- If you record other people: the capture accessory is the one place the outer display is yours — with the caveats above about it being an enhancement.
08 · Checklist
- Capture code audited for assumptions that
positionimplies direction - Decision made: virtual front camera, or the two physical camera types with a coordinator
- If you use a coordinator: printed all built-in camera types you capture from, including rear cameras, and held a strong reference for the life of the preview view
- Replacement camera chosen from
forwardFacingDeviceDescriptors, with the "no device resolved" path handled - Mirroring overridden from the direction map, with
automaticallyAdjustsVideoMirroringset tofalsefirst and re-applied after every input change - A new
RotationCoordinatorcreated on each camera switch - Accessory content built from ordinary views so its layout is checkable without a camera
- Off switch wired to a control in the capture interface; capture interface still complete with no accessory present
- Animated accessory content that pauses and resumes cleanly whenever the system withdraws it
- Capture paths tested on a device, not in Simulator
Sources: Apple Developer — Choosing a camera by the direction it faces, Registering a camera capture accessory on iPhone Duo, AVCaptureDeviceDirectionCoordinator, Build a great camera experience for iPhone Duo, and the October 2026 Hello Developer newsletter that announced both articles. Earlier context on the two front cameras is in our camera session notes.