How can I tell which DNG opcode belongs to which OpcodeList for a RAW image captured by AVPhotoOutput? I couldn't find any of the OpcodeList1, OpcodeList2 or OpcodeList3 tags in the DNG metadata inside AVCapturePhoto.metadata, but when exporting the photo into a DNG file to disk and extracting that DNG file's metadata using exiftool on a computer, I could see the opcodes in their respective opcode lists. Can I get the opcode lists without exporting into DNG data representation and then parsing the DNG file?

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?

I want to hide only the Cancel button of a modally presented SwiftUI PhotosPicker, so I'm using .photosPickerDisabledCapabilities(.selectionActions) with the default selection behavior: .photosPicker(isPresented: $isPresented, selection: $selection, maxSelectionCount: 5, matching: .images, photoLibrary: .shared()) .photosPickerDisabledCapabilities(.selectionActions) Cancel goes away as expected, but Add (the checkmark) stops working. Tapping it does nothing, the picker stays up and isPresented never becomes false. Pulling the sheet down doesn't close it either, so there is no way out of the picker. Without the modifier, Add works. WWDC23 session 10107 says that without continuous selection only Cancel is hidden and Add stays, so I expected Add to keep working. Seen on both the simulator (iOS 26.1 and 27.0) and a physical device, with Xcode 26.1.1, with and without preselected items. Q1. On a modal PhotosPicker, .photosPickerDisabledCapabilities(.selectionActions) hides Cancel, but Add then does nothing and the picker cannot be dismissed, not even by pulling it down. Is this a bug, or am I misusing the API? Q2. This is about the default modal PhotosPicker with both X and Add shown, without .photosPickerDisabledCapabilities(.selectionActions). With preselected assets, the callback returns the same result whether the user taps Add, taps X, or pulls the sheet down. Are there plans to provide a way to tell them apart?

Hi everyone, I recently updated my MacBook Pro (14-inch, M1 Pro) to macOS 27, and I've noticed a significant drop in the built-in FaceTime HD camera quality. The video feed looks incredibly grainy and noisy, almost like it's struggling with digital artifacts, even in well-lit rooms where it used to look perfectly crisp. Here is what I've tried so far to fix it: • Restarted the Mac multiple times. • Cleaned the physical camera lens with a microfiber cloth. • Tested across multiple apps (FaceTime, Zoom, Google Meet, and Photo Booth) - the graininess happens everywhere, so it isn't isolated to just one app. The camera worked beautifully on previous macOS versions (26.x), so this definitely feels like a software processing bug or an issue with how macOS 27 handles the camera. Is anyone else experiencing this on their M1 Pro machine after the update? Are there any known workarounds, or do we just have to wait for Apple to push a supplemental software patch? Thanks in advance for any insights!

Hi Apple team, I’m developing Awaira, an iPhone app that runs real-time, on-device camera detection during a user-initiated support session. Its purpose is to help users notice hand-to-hair behavior. The user explicitly starts and stops the session; the camera indicator remains visible; camera frames are processed on-device; and the app does not record or transmit video. A common user request is to continue the session while using another app. On Android, this can be implemented with visible foreground-service behavior. On iOS, the capture session stops when Awaira is no longer foreground. I found AVCaptureSession.isMultitaskingCameraAccessSupported and isMultitaskingCameraAccessEnabled. The documentation says iOS 18 apps using UIBackgroundModes = voip may support multitasking camera access, and Apple’s PiP documentation discusses video-call apps. We do not provide a genuine person-to-person VoIP or video-calling service, and we do not want to misuse the VoIP background mode or create a fake call solely to keep camera detection active. Could Apple clarify: Is there any App-Review-approved API or entitlement for this kind of explicit, visible, user-initiated on-device camera session to continue while another app is foreground? Is declaring voip and using the multitasking-camera API permitted only for genuine VoIP/video-call apps? If no current approved path exists, is there a recommended design pattern for this accessibility/health-oriented use case? We will only ship an implementation that complies with the intended purpose of Apple’s APIs and App Review Guidelines. https://developer.apple.com/documentation/avfoundation/avcapturesession/ismultitaskingcameraaccesssupported Thank you.

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!

"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.