Hi everyone, I've been reading about iPhone camera sensors recently, and there's something I've been wondering about. Apple has explained the benefits of Quad Bayer, especially pixel binning for low-light photography and high-resolution capture. But why not use a traditional Bayer sensor with Dual Pixel PDAF instead? As far as I understand, a native Bayer arrangement could potentially preserve more fine detail without requiring remosaicing. And if both sensors have the same size and pixel count, couldn't the Bayer sensor also produce a cleaner 12MP image by downsampling? I'm also curious about the microlens design. Some sensors use one microlens shared by four pixels for phase detection. Wouldn't individual microlenses potentially offer better spatial resolution? So my main question is: What hardware-level advantages make Quad Bayer worth choosing over traditional Bayer, despite the additional image reconstruction involved? Is it mainly about read noise, analog binning, power efficiency, autofocus, or something else? I'm not a camera engineer, just someone interested in understanding the technology behind iPhone cameras. I'd really appreciate any technical insight. Thanks!

I am encountering an issue where the Lock Screen Quick Action fails to visibly open my app. My app is a camera application that utilizes a CameraCaptureIntent to launch a standalone, lightweight camera view (accessible while the device is locked), distinct from the main application. Steps to Reproduce: Open the lightweight camera view using the Lock Screen Quick Action. From this view, launch the Main App. Lock the iPhone (put it to sleep). Attempt to launch the lightweight camera view via the Quick Action again. A slight animation occurs, but the camera view does not appear on screen. After multiple tests, it seems the view is actually launching but remains in an "invisible state." I suspect that the system hides the lightweight camera view when transitioning to the Main App, but fails to reset this hidden state when the Quick Action is triggered subsequently. I would appreciate any guidance on a potential workaround or confirmation if this is a known issue awaiting a system update.

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.

As a reminder, the recommended approach to monitor camera rotations, including on upcoming hardware, is to use the AVCaptureDevice.RotationCoordinator / AVCaptureDeviceRotationCoordinator API. In many common scenarios on iPhone Duo, proper use of the rotation coordinator is the only way to ensure that your camera previews and captures use the orientation expected by the user. AVCaptureVideoOrientation has been deprecated as of iOS 17.0 and iPadOS 17.0. When switching cameras in your app, make sure to create a rotation coordinator for that device. To ensure that your app has implemented the rotation coordinator API correctly, you should test different orientations and sizes of your app on an iPad with Stage Manager enabled. Additional information: Sample Code: Supporting device rotation in your camera app Tech Talk: Build a great camera experience for iPhone Duo WWDC23 session: Support external cameras in your iPadOS app

We're building a simple iPhone app that shows a live view from the rear camera in Picture in Picture while the user is in other apps. The camera feed is only displayed. It's never recorded, stored or transmitted, and the app has no network access. In testing on an iPhone 15 Pro (iOS 26.6.2) with Xcode 26.6, the camera keeps running behind PiP only when the app declares the voip background mode. Without it, as documented, isMultitaskingCameraAccessSupported is false and the capture session is interrupted with videoDeviceNotAvailableWithMultipleForegroundApps as soon as PiP starts. Our app isn't a calling app, so we don't want to rely on voip. Two questions: Is the com.apple.developer.avfoundation.multitasking-camera-access entitlement available to non-calling apps with a use case like this? If so, how should we request it? If not, is there any supported way for a non-calling app to keep a live camera preview running in PiP on iPhone? I'm happy to share a short screen recording of the prototype.

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?

Since upgrading to macOS 27 Golden Gate, my Mac Studio (M4) recognises my Logitech MX Brio 4K webcam, but no video feed is displayed. The camera appears to be detected by the system, but the video signal does not show up in: FaceTime Photo Booth Logitech Options+ I've spent quite a bit of time troubleshooting the issue, including following diagnostic steps suggested by Siri and Copilot, but everything points to a potential macOS-related problem rather than a hardware or configuration issue. Has anyone else experienced this with the MX Brio or other webcams on macOS 27 Golden Gate? I reported the issue to Apple through the Feedback app when Beta 1 was released, but so far I haven't received a response or found a workaround. Any insights or suggestions would be greatly appreciated. Thanks!

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.

“When the device opens or closes and the camera automatically changes, how does the systems decide which camera provides the best experience”???

I build Lumecast, a live-streaming app (custom AVCapture pipeline feeding WebRTC). Three questions:   1. Does iPhone Duo support AVCaptureMultiCamSession — specifically front + rear simultaneously? Our co-casting feature would let a solo host fill two panes with their face and what they're looking at. How should a continuous capture session (live broadcast, can't pause) respond to camera direction changes as the device opens and closes? Is there a recommended pattern for swapping to the Virtual Front Camera mid-session without a visible gap for viewers?  3. Which cameras are available to third-party apps in each posture (folded / half-open / fully open), and does availability change at a specific hinge state? Goal: a host folds or unfolds mid-broadcast and their audience never sees a dropped frame.

is AVCaptureMultiCamSession supported on iPhone Duo — specifically streaming two cameras that face opposite directions simultaneously (e.g. .builtInInnerUltraWideCamera + .builtInOuterUltraWideCamera, or the Virtual Front Camera plus a backward-facing camera)? I noticed the article recommends single-input reconfiguration over multi-cam; is that a performance recommendation, or is opposite-direction multi-cam unavailable on this device? Our use case is a live co-cast where one host fills two video panes: their face and what they're looking at.

According to Apple's press release (https://www.apple.com/pt/newsroom/2026/09/apple-debuts-iphone-18-pro-and-iphone-18-pro-max/): Variable aperture also provides more control for creative pros by giving them the ability to manually adjust any of the four aperture settings in the Camera app, and an API is available to developers for even more control across the aperture range in their apps. Can a DTS engineer specify the quoted API please? I can't see it anywhere in the documentation yet. What does it mean "even more control across the aperture range"? Will it be possible to set the aperture in a 0.0-1.0 range?

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs: How should apps preserve navigation and UI state when switching between the inner and outer displays? Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state? Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores. If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded? iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo. How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)? The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id:anchor:) for this transition. For more info, see Prepare your app for iPhone Duo. How can apps preserve what someone is doing when switching displays or folding/unfolding? Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. How does actively playing video behave through the hinge angle animation? The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically. If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests? When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo. How should apps handle the keyboard and text input when the device folds or unfolds while typing? As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField. If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene? When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

Hi— App review said: The app uses one or more entitlements which do not have matching functionality within the app. Apps should have only the minimum set of entitlements necessary for the app to function properly. Please remove all entitlements that are not needed by the app and submit an updated binary for review, including the following: • com.apple.security.device.camera • com.apple.security.network.server …but my app has a feature that does use the camera (continuity camera for macOS, and a bonjour feature for finding other local app instances, establishing a link, and sending data to other instances. I’ve tried declaring/justifying talking about it in App testing info and in my reply to the reviewer, about how to access the features that require it. do I really not need these entitlements and only seems like I would? do I simply test app scheme Release > no debug executable with fresh sandbox and see if features break? But no declaring these things seems like the opposite of what Apple would want… it seems like explicitly calling out these features makes a lot more sense? this is my first app— thank you

For the new IOS 27.0 system on iPhone 18 pro demo, the camera app have a new feature to let users adjust camera focusing from AF to MF. This feature does not require the newest camera module. Therefore, all previous models should be able to have this feature, especially useful via camera control slider. How to get attention of apple camera software development team to work on this...

An incomprehensible error occurs whenever I try to access Main Camera features. I have already acquired the Main Camera entitlement and granted the required permissions, yet the error persists. To make matters worse, even Apple’s provided sample code triggers the exact same issue. The error message is far too uninformative to diagnose the root cause, and I urgently need a resolution as this is completely blocking progress. Multiline [C:1-2] Error received: Invalidated by remote connection. failed to observe with mask <BLSXPCBacklightProxyObserverMask: 0x108accf80; didUpdateToState: YES; eventsArray: YES> error:<XPC error received on message reply handler (3:BSServiceConnectionErrorDomain) "The operation couldn’t be completed. XPC error received on message reply handler"> non-launching port is incompatible with service identifier "com.apple.PointerUI.pointeruid.default-service" nw_socket_copy_info [C1:2] getsockopt TCP_INFO failed [102: Operation not supported on socket] nw_socket_copy_info getsockopt TCP_INFO failed [102: Operation not supported on socket] Unable to find a compatible slice for binary archive at /System/Library/Frameworks/CoreImage.framework/ci_uberwrapper_bin.metallib *** Assertion failure in void ar_session_request_authorization(ar_session_t _Nonnull, ar_authorization_type_t, __strong ar_authorization_results_handler_t _Nonnull)_block_invoke(), session.m:1491, reason: This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist. <NSXPCConnection: 0x10e68dcc0> connection to service with pid 86 named com.apple.arkit.service.authorization: Exception caught during invocation of reply block to message 'requestAuthorizations:withReply:'. Exception: This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist. ( 0 CoreFoundation 0x0000000198b756d4 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1205972 1 libobjc.A.dylib 0x000000018d3a71cc objc_exception_throw + 88 2 CoreFoundation 0x0000000198b755c0 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1205696 3 ARKitCore 0x00000002bbd640cc 53FDDDD4-8DD1-3E86-ACB0-8867D29AF781 + 479436 4 CoreFoundation 0x0000000198b7c5b4 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1234356 5 CoreFoundation 0x0000000198b79558 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1221976 6 Foundation 0x000000019de4220c 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2109964 7 Foundation 0x000000019de41dd0 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2108880 8 Foundation 0x000000019de4651c 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2127132 9 libxpc.dylib 0x00000002c43d5a00 CE0BB604-B358-3F22-B1DA-FFACEFCA20AD + 150016 10 libxpc.dylib 0x00000002c43c5678 CE0BB604-B358-3F22-B1DA-FFACEFCA20AD + 83576 11 libdispatch.dylib 0x00000002c41045fc 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 108028 12 libdispatch.dylib 0x00000002c41083ec 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 123884 13 libdispatch.dylib 0x00000002c40f37c0 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 38848 14 libdispatch.dylib 0x00000002c40f4450 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 42064 15 libdispatch.dylib 0x00000002c40fe3ec 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 82924 16 libdispatch.dylib 0x00000002c40fdd18 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 81176 17 libsystem_pthread.dylib 0x00000002c4364e34 _pthread_wqthread + 292 18 libsystem_pthread.dylib 0x00000002c4362910 start_wqthread + 8 ) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist.' *** First throw call stack: (0x198b756c8 0x18d3a71cc 0x198b755c0 0x2bbd640cc 0x198b7c5b4 0x198b79558 0x19de4220c 0x19de41dd0 0x19de4651c 0x2c43d5a00 0x2c43c5678 0x2c41045fc 0x2c41083ec 0x2c40f37c0 0x2c40f4450 0x2c40fe3ec 0x2c40fdd18 0x2c4364e34 0x2c4362910) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist.' *** First throw call stack: (0x198b756c8 0x18d3a71cc 0x198b755c0 0x2bbd640cc 0x198b7c5b4 0x198b79558 0x19de4220c 0x19de41dd0 0x19de4651c 0x2c43d5a00 0x2c43c5678 0x2c41045fc 0x2c41083ec 0x2c40f37c0 0x2c40f4450 0x2c40fe3ec 0x2c40fdd18 0x2c4364e34 0x2c4362910) libc++abi: terminating due to uncaught exception of type NSException Xcode has killed the LLDB RPC server (pid: 2210) to allow the debugger to detach from your process. BlockQuote visionOS 27 beta 5

We use a single AVCaptureSession with AVCaptureVideoPreviewLayer and AVCaptureVideoDataOutput (preview-sized buffers, BGRA). When we increase videoZoomFactor, beyond a certain zoom level the image from AVCaptureVideoDataOutput no longer zooms further, while AVCaptureVideoPreviewLayer continues to zoom with the same zoom control. The preview and the video-data output therefore diverge. This behavior appears when the active camera is a physical lens device — wide, ultra-wide, or telephoto (e.g. builtInWideAngleCamera, builtInUltraWideCamera, builtInTelephotoCamera, or similar). It does not appear when the active input is a virtual / multi-camera (e.g. triple camera, dual-wide, or other system multi-camera). Are there known conditions under which this mismatch between preview and video-data output is expected? Thank you.

Does iOS 27 provide an API which allows developers to set the iPhone 18 Pro camera's aperture? If it does, is the aperture going to be limited to just 4 discrete settings (like in the Camera app and like mentioned in the Tech Specs for the 18 Pro) or does the hypothetical iOS API allow us to set the aperture to a continuous value in the 0.0–1.0 range (similar to how a camera's focus can be set)?

I am able to capture 48mp photos using .builtInWideAngleCamera, but it seems like .builtInTripleCamera is capped at 12mp? Is there a way to capture 48mp photos using .builtInTripleCamera? Because .builtInTripleCamera provides smooth transition between cameras during zooming, and I'd like to keep this behavior. New iPhone 17 Pro have all their cameras at 48mp. Is there a chance that their .builtInTripleCamera is capable of capturing 48mp? Or is this an API limitation?