Hinge, multitasking and scenes

Three capabilities that are unique to iPhone Duo, in rising order of ambition: reacting to the hinge, participating in Split View, and putting your own UI on both displays at once.

The hinge

The system itself responds to the hinge — the wallpaper reacts to the angle with a zoom effect as the device opens. Apps can read the same signal.

Use the onHingeChange modifier in SwiftUI, or UIHingeInteraction in UIKit. Both give you:

• a coarse status — closed, partially open, fully open
• a continuous angle, updated live

onHingeChange hands your closure the previous and current hinge context. UIHingeInteraction hands its handler the interaction and an Update instead, and also fires when the view moves between hierarchies.

Watch the types — they differ between frameworks:

• SwiftUI's angle is an Angle; UIKit's is a CGFloat in radians.
• SwiftUI's DeviceHinge.Status is a struct (a switch needs default); UIKit's UIHinge.Status is an enum with a fourth case, .unknown.
• The system decides the status from the angle and device orientation, so don't recompute it from thresholds. Update rate and precision are system policy — don't assume a frequency.

Full signatures, a reusable normaliser, and effect patterns are in ../iphone-duo-dual-pane-patterns/SKILL.md.

Two things to check before using the value:

1. Is there a hinge at all? A nil hinge means the app is running on a device without one. Same binary, most devices.
2. Is the device in a state you care about? Usually you only want updates while partially open — and you need an else branch that resets whatever the angle was driving, so the effect doesn't stick at a stale value once the user opens the device flat.

Then map the angle to your parameter and update state.

What the hinge is for

Interactions and effects. The angle is a live, continuous input stream — it behaves like a sensor, and it suits things that respond continuously. Driving a pitch bend from the fold angle, the way a whammy bar works, is the right shape of idea.

Not layout. Do not lay out views from the hinge angle. Layout has proper tools that are declarative, testable and correct on devices with no hinge: arrangements and reserved regions, in ../iphone-duo-adaptive-layout/SKILL.md. Reaching for the angle here produces layout that thrashes during the fold and breaks everywhere else.

Split View multitasking

Every app participates. Two apps sit side by side, created with the familiar home gesture — drag an app to one side and drop it. There's a second layout too, stacking video and apps together when Picture-in-Picture is pinned. Your app handles both identically.

If the app already supports resizing on iPad or under iPhone mirroring, it is most of the way there. The system gives you size classes and scene geometry to make layout decisions from; the general guidance in ../iphone-duo-readiness/SKILL.md applies unchanged.

The detail worth testing: in Split View, vertically laid out bar content can appear on either side of your app, depending on which half you occupy. Drag the app to both sides in Device Hub and check that asymmetric safe area handling holds up.

Multiple scenes

iPhone Duo is the first iPhone to support multiple simultaneous instances of an app's UI. If the app already supports this on iPad, it works here too.

One behavior is genuinely new, though:

New windows cannot be created on the outer display. That is reserved for the inner display, and the availability changes as the user opens and closes the device. This dynamic availability doesn't exist on iPad.

Consequences:

• Handle errors when requesting new scenes. A request that always succeeded on iPad can now fail.
• Prefer UIWindowSceneActivation, which automatically hides itself when new windows aren't available — so users never tap an affordance that can't work.

Scene accessories

Scene accessories pair additional content with your app's main UI on another display. They aren't Duo-specific — the same mechanism backs using an iPhone as a controller for a game on an external display — but iPhone Duo gives every user two displays to work with.

The system controls availability dynamically. Accessories are enabled by default and can be toggled at any time, so observe availability rather than assuming it: use observation tracking, or the onAvailabilityChange modifier, and reflect the current state in your UI (disabling a toggle button when the accessory can't be shown, for instance).

CameraCaptureAccessory

For camera apps, CameraCaptureAccessory puts UI on the outer display while the app's main UI stays on the inner one. The person being photographed can see something while you shoot — showing a child something entertaining, or running a teleprompter for a subject on camera.

Two conditions gate availability: the app must be full screen on the inner display, and it must have an active camera session.

Register the accessory on the same view as your camera UI. Scoping it that way means the accessory appears and disappears with the camera view itself, without any extra lifecycle code. In SwiftUI that's the sceneAccessory modifier applied to the camera view.

Adding a toolbar control to toggle the accessory is a natural pairing — drive it from your model, and use onAvailabilityChange to disable the control when the accessory isn't available, such as when the device is closed.

Camera specifics — which physical camera is streaming, and which way it is actually facing once two displays are involved — are in ../iphone-duo-camera/SKILL.md. That question gets genuinely subtle, and the direction coordinator exists to answer it.

Checklist

1. Support resizing first. Split View correctness follows from it.
2. Test the app on both sides of a Split View, in every pose.
3. If the app supports multiple windows, handle scene-request failure and adopt UIWindowSceneActivation.
4. Consider whether a hinge-driven effect genuinely improves the app — then guard for nil hinge and reset state when the device leaves the range you care about.
5. For camera apps, evaluate whether a CameraCaptureAccessory on the outer display would help the person in front of the lens.