I am developing CineZoom, part of CameraControl, a remote camera-direction system (macOS app controlling an iPhone capture engine). Its core requirement is a smooth, repeatable cinematic zoom. On iPhone 17 Pro (iOS 26.5.1), using the physical Back Ultra Wide camera at 3840x2160, 60 fps, a single native ramp(toVideoZoomFactor:withRate:) from 1.7x to 2.1x over 5 seconds shows a visible stutter. I isolated it with a minimal diagnostic app (no networking) and analysed four tripod recordings frame by frame, in two locations with different lighting. The results are consistent across all four: Jitter below 2.0x: while the zoom factor is below 2.0, the image centre shifts about 2.8 px RMS between consecutive frames (peaks ~5 px), alternating almost every frame (26-28 Hz). Above 2.0x, during the same ramp at the same speed, it drops to 1.2-1.5 px. Sharpness step at 2.0x: centre-crop sharpness drops by 23-31% within a few frames exactly when the zoom factor crosses 2.0. There is no consistent effect at the reported secondaryNativeResolutionZoomFactors value (1.7838). The zoom command path itself is correct: the zoom measured from the image matches videoZoomFactor throughout, with no dropped or duplicated frames. Questions: Is this expected behaviour for the Ultra Wide camera in this zoom range? Is the jitter related to video stabilization or to how the sensor crop is positioned in this readout mode? Is there a public API that reports or controls the zoom factor at which this transition happens, so an app can plan around it? What configuration do you recommend for a smooth continuous video zoom across 1.7x-2.1x on this camera (format, stabilization mode, constituent-camera switching)? Are there existing APIs that would let an app detect or compensate this (per-frame stabilization/crop metadata, consistent processing during zoom, or a reduced-processing video stream)? I have a full technical report, per-frame measurements, charts and the original recordings, and I am happy to share them. Thank you!

In the old simulator you were able to simply drag a photo or video from your desktop into the photos app within the simulator in order to use it for testing. That doesn't seem to be working yet in Device Hub. Is there a workaround or are we just waiting on this to be fixed?

On an iPhone 18 Pro running iOS 27, I’m seeing an interaction between locked frame timing and custom exposure. I configure the wide camera for 4K at 29.97 fps: input.activeLockedVideoFrameDuration = CMTime(value: 1001, timescale: 30000) With aperture and ISO fixed, I set exposure using the iOS 27 setExposureModeCustom(lensAperture:duration:iso:completionHandler:) API. A controlled comparison produced: 10 ms requested: timing lock ON → 10.000 ms; OFF → 10.000 ms. 16 ms requested: timing lock ON → 16.129 ms; OFF → 16.129 ms. 20 ms requested: timing lock ON → 16.667 ms; OFF → 20.000 ms. “OFF” means ordinary minimum and maximum frame durations both set to 1001/30000 seconds. These are exposure values from per-frame camera metadata after valid completion timestamps and a settling period. The behaviour occurs both idle and during recording. With the timing lock enabled, delivered frame timestamps show exact 30000/1001 pacing. Without it, fully manual capture measured approximately 29.964 fps. Separately, with shutter fixed at 20 ms but ISO automatic, the locked-timing configuration held 20 ms and exact 29.97. That suggests exposure ownership affects the behaviour. The documentation (https://developer.apple.com/documentation/avfoundation/avcapturedeviceinput/activelockedvideoframeduration) recommends exposure durations of half a frame or less to maintain full dynamic range, but doesn’t explicitly describe a duration clamp. Is this expected behaviour? Does fully manual exposure impose a half-frame ceiling when locked frame timing is active? Is there an API to query that effective limit? The format’s advertised exposure range includes 20 ms. Is there a supported way to retain exact fractional frame timing and a longer fully manual exposure? I can provide a minimal reproducer and device diagnostics.

Physical camera sensors deliver pixel buffers in native landscape orientation, requiring coordinate transformations when rendering into portrait or split viewports. What is the recommended pipeline design using AVCaptureDeviceDirectionCoordinator and AVCaptureDevice.RotationCoordinator to guarantee that live preview layers and photo captures remain upright across varying fold angles without manual Core Graphics or Core Image buffer rotation passes? Are there specific considerations when the view hierarchy bridges across the physical hinge division?

We are very interested in the new Virtual Front Camera capability on iPhone Duo. When the physical chassis opens or closes, how does the Virtual Front Camera handle the underlying optical handoff? Specifically, does this transition occur seamlessly within an active AVCaptureSession / AVCaptureVideoDataOutput pipeline without interrupting delivery of video frames, or does it trigger reconfiguration notifications that require pausing the session? Additionally, can the Virtual Front Camera be paired with a rear capture device inside an AVCaptureMultiCamSession while maintaining real-time performance and reasonable thermal headroom?

In the current Xcode iPhone Duo simulator runtime, AVCaptureDevice.DiscoverySession does not expose physical or simulated camera devices, returning empty arrays and necessitating custom synthetic mock pipelines for UI and kinematic tests. Are there plans to introduce synthetic camera device emulation directly within the Duo CoreSimulator runtime? In the interim, what is Apple’s recommended architecture for verifying camera UI, preview rendering, and capture triggers on the Duo simulator target without diverging from production AVFoundation pipelines?

Hello team, When configuring an AVCaptureMultiCamSession or consuming the new Virtual Front Camera, what is the recommended architecture to avoid frame drops or pipeline rebuilds (AVCaptureSessionRuntimeError) during dynamic posture transitions (from folded to unfolded / half-open)? Specifically: Does the Virtual Front Camera handle the lens handover internally with continuous timestamps in CMSampleBuffer, or does the underlying device switch trigger a device disconnect/reconnect notification that requires re-attaching inputs? How are the optical intrinsics (matrix_float3x3) and lens distortion coefficients updated through the hinge motion? Can we rely on continuous metadata attachments on each frame during the transition, particularly if running real-time CoreML / Vision processing? Thanks!

After watching "Leverage multiple displays and scenes on iPhone Duo" and "Build a great camera experience for iPhone Duo", we have four questions about the outer display while the device is open: Does a view hosted in CameraCaptureAccessory receive touch input on the outer display, or is it display-only? The accessory is described as available when the app "has an active camera session." Does that require a running preview layer or an attached output (photo, movie or data), or is a running AVCaptureSession with an input enough? Is a session whose main purpose is to host the accessory a supported use? Can AVCaptureMultiCamSession run the inner (under-display) front camera and the outer front camera at the same time on iPhone Duo? If so, which device-type combinations are supported, and are there thermal or power limits? Is CameraCaptureAccessory the only way for an app to show content on the outer display while the inner display is live, or are scene accessories that don't depend on the camera planned? Our use case is not photography. We're exploring a companion view for a second person sitting across from the device owner, so we want to understand whether the camera accessory is the right tool before designing around it.

"Build a great camera experience for iPhone Duo" covers the device open and the device closed, including reconfiguring the session from AVCaptureDeviceDirectionCoordinator's change handler when the forward-facing camera changes. It does not cover the partially open pose, which "Leverage multiple displays and scenes on iPhone Duo" treats as a first-class hinge state with a continuous angle. Consider a camera app that keeps a live preview on screen and adopts AVCaptureDevice.RotationCoordinator — the documented remedy for cases like the square front sensor on iPhone 17, where a hard-coded 90° leaves the preview tilted — applying videoRotationAngleForHorizonLevelPreview to both the preview and the capture connection. In the partially open pose the two halves are at different physical attitudes: one stands up, the other lies flat. Which camera does AVCaptureDeviceDirectionCoordinator report as forward-facing while the hinge status is partially open? Does the hinge angle affect that decision? RotationCoordinator derives its angle from device attitude. With the two halves at different attitudes, which one does videoRotationAngleForHorizonLevelPreview reflect — the half carrying the active camera, the half hosting the preview layer, or a single device-level reference? If an app deliberately keeps the rear camera on the scene while its preview is drawn on the half facing the user, is that a supported configuration, or is the coordinator expected to override that choice? Is any of this modelled in the iPhone Duo simulator, or does the partially open pose require real hardware to test? Question 4 matters for planning: building against a rotation value that only appears on device would be worth knowing about before the hardware ships.

Hi! We run continuous 2D human body-pose estimation on a front-facing camera feed: one person, full body in frame, standing a meter or two away, 30-60fps. With iPhone Duo open, the camera that faces the person looking at the inner display is the under-display inner camera (builtInInnerUltraWideCamera). Published specs cap it at 1080p at 30 or 60 fps, and it is presented as the FaceTime camera. Two things are unclear from the camera tech talk and the specs: Is that 1080p format a native readout we can feed to Vision body pose, or a preview-oriented stream whose effective detail is too low for full-body pose at that distance? Is third-party use of this camera supported for a long-running analysis session, or is it intended only for video calls and live previews? Thanks

For a user-selected photo wallpaper on iPhone Duo, does iOS use one source image and automatically adapt or crop it for the outer and inner displays, or can users assign separate images to the outer and inner displays? If one image is used, is the crop or focal position shared between both displays, or can the user adjust them independently?

Hello. Any recommendations on approach to placing a camera shutter button in half-open state? Also, other controls, like capture modes, etc. Camera preview is fullscreen.

When a persistent camera session such as FaceTime is active on the inner display, the under-display camera becomes visible. What is the behavior when such a session is active and the user switches to my app, where some content, such as Navigation titles, normally sits in the region of the camera? Will the camera become hidden again and show in FaceTime that the call participant's camera is unavailable, or is there some other behavior of which I as an app developer should be aware? Thank you!

Hello everyone! Does the ARKit ARSession qualify for an active camera session? Reading through the documentation, I understand that showing content on both iPhone Duo screens at the same time is only possible by using CameraCaptureAccessory. ARSession drives the camera but doesn't vend an AVCaptureSession that the app owns, so it isn't clear whether the availability check keys off app-owned AVCaptureSession state specifically, or off the camera actively streaming for the app. If it is currently not possible, do you see any way or workaround to show the camera stream on the outside display while the inner display is displaying an AR view? Best regards, André N.

Any tips on designing for half-open pose? Also how to detect that pose.

Any tips on positioning a shutter button on camera screen (fullscreen preview) when device is in half-open state? As well as other centred controls (camera mode, etc)? How to handle hinge area updates? Thanks

We present custom content on the outer display through CameraCaptureAccessory while a capture session runs (iOS 27.1). Our app is used in the partially folded "laptop" pose: the inner display is portrait with a horizontal fold, controls below the fold, content above it. The person in front of the outer camera sits opposite the device, so for them the outer display's long edge is horizontal. In Simulator (iPhone Duo, iOS 27.1) the accessory scene is always laid out as 466×678 pt — portrait — regardless of the pose, and regardless of the app's UISupportedInterfaceOrientations. Our landscape content is therefore letterboxed into a narrow band instead of filling the display. On device, what interface orientation does the accessory scene get in the partially folded pose? Does the system rotate it to match the physical orientation of the outer display, or is it always the outer display's portrait orientation? Is Simulator's behaviour here representative, or is accessory-scene orientation one of the things that only behaves correctly on device? If we have to compensate ourselves, is there a supported way to learn the outer display's physical orientation from inside the accessory scene — reserved regions, the scene's interfaceOrientation, something else? We would rather not hardcode a rotation. Does UIRequiresFullScreen (deprecated in iOS 26) or the app's supported interface orientations constrain the accessory scene in any way?

Hi, Can you talk about what happens with ARKit by default when the unfolding occurs in a normal ARWorldTrackingConfiguration - does the ARSession pause at all or is tracking completely uninterrupted? Does it swap cameras when using ARFaceTrackingConfiguration! Thanks.

Hi! We run continuous 2D human body-pose estimation on a front-facing camera feed: one person, full body in frame, standing a few meters away, about 30 fps. With iPhone Duo open, the camera that faces the person looking at the inner display is the under-display inner camera (builtInInnerUltraWideCamera). Published specs cap it at 1080p at 30 or 60 fps, and it is presented as the FaceTime camera. Two things are unclear from the camera tech talk and the specs: Is that 1080p format a native readout we can feed to Vision body pose, or a preview-oriented stream whose effective detail is too low for full-body pose at that distance? Is third-party use of this camera supported for a long-running analysis session, or is it intended only for video calls and live previews? Thanks

“Can iphone duo make it easier for a creator to record themselves while simultaneoulsy seeing or controlling what the other camera is capturing“???