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?

I am a private individual working on a personal panorama viewing and reprojection project. I have been investigating the geometry of panoramas produced by the iPhone Camera app, with extensive analytical and research assistance from OpenAI's ChatGPT. My goal is to determine the physical viewing direction (longitude and latitude, or equivalently a 3-D viewing ray) corresponding to each pixel in a finished iPhone panorama. I have been able to recover much of this geometry from information contained in the panorama itself. Controlled tests on several iPhone models indicate that I can accurately determine the effective focal length of the perspective source camera, camera rotation during capture, endpoint geometry, horizontal field of view, and gravity-relative camera orientation. The remaining problem is the absolute vertical/latitude mapping in the finished panorama. The gravity/orientation information allows me to determine where a known physical latitude—for example, the true horizontal plane (0° latitude)—falls in the individual source-camera frames. However, I have not found a documented way to determine exactly where those source-frame viewing rays are placed vertically in the final panorama bitmap. My investigation suggests that the Camera app performs additional geometric processing during panorama assembly, including geometric/perspective correction and the selection, cropping and/or rotation of image slices before they are blended into the panorama. What I have not been able to determine is whether the information needed to reconstruct that source-ray-to-finished-pixel mapping is retained anywhere in the finished panorama or is available through a supported Apple API. My primary question is therefore: Is there a documented or supported way to determine the physical viewing ray corresponding to each pixel in a panorama produced by the iPhone Camera app, including its absolute vertical/latitude mapping? More specifically: Is the projection used for the finished Camera panorama documented? Is the gravity-relative orientation or vertical reference of that projection available through supported metadata or an API? Is sufficient information retained in the panorama to reconstruct the geometric correction and placement applied to source images/slices during panorama assembly? If that information is not retained in the finished image, is there another supported framework or API that provides it during or after panorama capture? I am not trying to reproduce Apple's image blending or other proprietary image-processing algorithms. I simply want to interpret the geometry of the finished image accurately enough to reproject it—for example, to cylindrical or equirectangular coordinates—and assign physical longitude and latitude to its pixels. I have controlled test panoramas from multiple iPhone generations and considerably more technical detail about the investigation. I would be happy to provide example files, measurements, or additional information if that would be helpful. Even confirmation that the required vertical-placement information is not retained or exposed would be very useful.

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.

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