Contents

Registering a camera capture accessory on iPhone Duo

Provide content to the person in front of the camera by pairing it with your capture interface.

Overview

Consider an app that records someone reading from a script. The person holding the device sees the capture interface, and the person in front of the camera sees nothing. They look away from the lens to read, or they memorize the script and lose the take. On iPhone Duo, an outer display faces the same way as the camera, so the app presents the script to the person who needs to read from it.

[Image]

Your app declares the content as a UISceneAccessory and attaches it to the view that shows your capture interface. The system decides when and where to present it. Presentation happens while your app is in the foreground with an active capture session, while the capture interface runs on the inner display. Because the decision belongs to the system, treat accessory content as an enhancement.

Decide what to show on the outer display

Decide what the person in front of the camera needs to see while recording. For example, your app can scroll a script at a readable pace, count down before recording starts, or show how much of the subject the camera sees.

Consider the following before you design the content:

  • Let the system choose where the content appears. Your app declares a kind of content and passes no display, capture session, or camera reference. The system finds the active capture session itself.

  • Keep any interaction minimal. Anything your app shows on the outer display is an enhancement. The display accepts touch, which suits a single capture task such as tapping a preview to focus, rather than a second interface. Keep all essential controls in your capture interface, because the system can withdraw accessory content at any time.

  • Expect the content to appear and disappear on its own. The system decides when to present the content, based on conditions outside your app.

Design your capture interface so it works when no outer display exists, and when the system presents nothing there. Accessory content enhances your app, and never carries a task your app can’t complete without it.

Register content on your capture interface

To scope content to the camera, register the accessory on the same view that shows your capture interface. The system presents your content only while that interface is onscreen, and stops when someone navigates away. Registration returns an object that reports whether the system can present the content. Later sections use that object to respond to availability and to turn the content off.

The system assigns the session role for the accessory’s scene, and your app never sets it. Unlike ordinary window scenes, accessory scenes have no project-level configuration, so a scene manifest entry for one has no effect. If your scene delegate handles several kinds of scene, compare the session role against windowCameraCaptureAccessory to identify this one.

Share state with your accessory content

Your capture interface and your accessory content belong to the same capture session, so both need the same state. Rather than sending updates to your accessory content, give it the object your app already uses, and let each side read what it needs. A control the subject taps on the outer display then changes what the person holding the device sees, with no message passing in between.

Respond to changes in availability

Availability tells you whether the system can present your content, and only the system sets it. Turning the content on and off is your app’s decision, and the registration keeps the two separate. When the system can’t present anything, hide the outer display controls.

Availability changes for reasons your app doesn’t cause. The system presents the top-most registration of a kind. Navigating to a view that registers its own content makes the previous one unavailable, and going back restores it. Availability also follows the device and the capture session. Content goes away when capture stops, when your app leaves the foreground, or when someone folds the device closed.

When the system can’t present anything, the registration stays inactive and availability stays false, which means one code path works everywhere. Accessories of different kinds never compete. An app that shows slides on a connected display can present capture content on the outer display at the same time.

Let people turn the content off

Rather than unregistering the accessory, give people a control in your capture interface that turns the content off. Turning the content off says nothing about whether the system can present anything.

Accessory content is on by default. Turning it off dismisses the content, and the views come and go the way your main scene’s do. Keep any state that has to persist in your model rather than in the view that presents it.

Test your accessory content on device

Create your app’s accessory content from ordinary views, so you can check its layout in previews or in Simulator, and confirm that it reads the same state as your capture interface.

Because Simulator doesn’t have a camera, always test anything that depends on camera capture on a device before you ship your app. The system presents content only when the device is open, your app is in the foreground, and a capture session is running.

See Also

Capture sessions