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

On iPhone 14 Pro and later, the system flashlight in Control Center can adjust beam width (narrow ↔ wide). As far as I can tell, AVCaptureDevice only exposes torchMode, torchLevel and setTorchModeOn(level:) I found nothing related to beam width Is there any supported way for a third-party app to control the torch beam width? If not, is this on the roadmap?

Hello Apple AVFoundation team, Could you clarify the supported iPhone models and OS versions for standalone locked video frame duration using AVCaptureDeviceInput.activeLockedVideoFrameDuration? The API is documented as available from iOS 26.0, but I understand that OS availability alone does not mean every camera device/configuration supports it. I have read the API documentation and the DTS reply in iPhone 17 Pro's Genlock feature, but could not find a model compatibility list for the standalone locked-duration API. Scope: I am investigating actual capture timing for multi-iPhone motion capture. This question is about locking each camera's frame period using its internal timing, without an external genlock accessory. I am not asking about encoding a constant-frame-rate file, ordinary equal min/max frame durations, timecode metadata, or synchronizing the first exposure across phones. Physical-device test iPhone 16 Pro, iOS 26.2 (23C55). Built with Xcode 26.3 and the iOS 26.2 SDK. One AVCaptureSession, one physical rear .builtInWideAngleCamera input, and one AVCaptureVideoDataOutput. 8-bit SDR 420v formats, tested at 1920 x 1080 and 3840 x 2160, each at 30 and 60 fps. Auto video frame rate disabled; no spatial video capture or multicam session. Manual exposure approximately 2 ms, shorter than half a frame at both tested rates. The session is running and delivering frames. Two separate probe runs produced the same results, including capability readbacks after a settling period. For all four tested configurations: input.isLockedVideoFrameDurationSupported = false device.minSupportedLockedVideoFrameDuration = kCMTimeInvalid input.activeLockedVideoFrameDuration = kCMTimeInvalid device.isVideoFrameDurationLocked = falseOrdinary activeVideoMinFrameDuration and activeVideoMaxFrameDuration can both be set to the requested CMTime(value: 1, timescale: 30) or CMTime(value: 1, timescale: 60), and frames are delivered. This is only a configuration readback, not a claim of exact capture timing in the ordinary mode. The app directly queries the public support properties; it has no model whitelist. It does not attempt to set a valid locked duration when support is false, as the documented setter contract would reject that. These tests cover the selected formats, not every camera/format on this phone. Questions Which iPhone models support this standalone API? In particular, is false expected on iPhone 16 Pro? Is there an official compatibility list covering iPhone 13/14/15/16 and iPhone 17 models? Is the iPhone 16 Pro result a hardware capability restriction, an iOS 26.2 limitation/known issue, or a configuration requirement? Is there a released iOS version that enables this on iPhone 16 Pro, or is newer hardware required? What is the minimum supported capture configuration and correct time to query support? Are there restrictions involving the physical versus virtual camera input, pixel format, SDR/HDR, or exposure mode that could explain this result? If so, which configuration should be tested before concluding that the device does not support it? On supported hardware, can this standalone lock be enabled without an external accessory or a special entitlement, independently of follow(_:videoFrameDuration:delegate:)? Relevant documentation: activeLockedVideoFrameDuration isLockedVideoFrameDurationSupported minSupportedLockedVideoFrameDuration I can provide a focused reproducer if needed. Thank you for clarifying the device requirements and whether an OS upgrade can change the result.

Hi everyone, I'm developing an iOS camera app that aims to record 4224×3024 Open Gate video at 60fps in 10-bit HEVC with Apple Log 2. Native Apple ISP-processed Apple Log 2 capture works at 3840×2160/60fps. However, at 4224×3024/60fps, the tested capture configuration only provides Bayer RAW (btp2). I've successfully decoded ProRes RAW using Apple's decoder into linear Rec.2020 and applied the published Apple Gamut and Apple Log 2 transforms. However, the resulting chroma is only approximately 72–74% of the native ISP output in controlled color-chart comparisons. I've also confirmed that VTRAWProcessingSession and related RAW processing controls are not publicly available to iOS apps in the iPhoneOS 27.0 SDK. My questions are: Is there a public iOS API that applies the same color and tone rendering as Apple's native camera ISP to captured Bayer RAW or ProRes RAW? Is there a supported configuration for obtaining full-resolution 4224×3024/60fps ISP-processed Apple Log 2 output (x420 or x422), without preview proxies or upscaling? If neither is supported, what is Apple's recommended approach? Is this a hardware limitation or a public API limitation? The goal is to use Apple's official color processing pipeline without empirically fitted matrices, LUTs, or arbitrary color corrections. Any guidance would be greatly appreciated. Thank you!

Hi, I’m building an app that counts push-ups with the phone on the floor. It currently uses ARKit and TrueDepth to measure the distance between the camera and the user’s face. I want to support iPhone Duo too, but I don’t have one. I only have an iPhone 17 Pro. I watched the camera presentation and saw that depth is supported when accessing the individual cameras. I’m trying to understand what that means for my app. Can either front camera provide continuous depth through AVCaptureDepthDataOutput, or is it only available when taking photos? Does it give actual distances in metres, or relative depth estimates? The face would usually be around 20 to 80 cm from the camera. Also, is there an equivalent camera mode on my iPhone 17 Pro that I could use to test the same approach, or would I need an actual Duo? It’s okay if counting is less accurate than with TrueDepth. I mainly need to detect the user moving down and back up reliably. Thank you!

I am working on a computational photography research project involving multi-exposure HDR reconstruction using Bayer RAW and Apple ProRAW captures. I would like to clarify the radiometric interpretation of Apple ProRAW and the availability of Bayer RAW capture through AVFoundation. My questions are: On current iPhone Pro devices, is it possible for third-party apps to capture and export true Bayer-pattern RAW DNG files through AVFoundation, rather than Apple ProRAW linear DNG files? If so, which availableRawPhotoPixelFormatTypes correspond to Bayer RAW, and what device or format restrictions apply? Apple ProRAW appears to be demosaiced and computationally processed, and may include multi-frame fusion. Is the decoded ProRAW image intended to be radiometrically linear and scene-referred? For a bracketed ProRAW sequence captured with fixed ISO, white balance, lens, and focus, but different exposure times, can one assume that the decoded linear pixel values Y_i(p) satisfy an exposure-proportional model in non-saturated regions, such as Y_i(p) ≈ t_i R(p), across brackets? This question is about radiometric consistency for algorithmic use, not about visual editing or tone mapping. Thank you for your help.

I am working on a computational photography research project involving multi-exposure HDR reconstruction using Bayer RAW and Apple ProRAW captures. I would like to clarify the radiometric interpretation of Apple ProRAW and the availability of Bayer RAW capture through AVFoundation. My questions are: 1.On current iPhone Pro devices, is it possible for third-party apps to capture and export true Bayer-pattern RAW DNG files through AVFoundation, rather than Apple ProRAW linear DNG files? If so, which availableRawPhotoPixelFormatTypes correspond to Bayer RAW, and what device or format restrictions apply? 2.Apple ProRAW appears to be demosaiced and computationally processed, and may include multi-frame fusion. Is the decoded ProRAW image intended to be radiometrically linear and scene-referred? 3.For a bracketed ProRAW sequence captured with fixed ISO, white balance, lens, and focus, but different exposure times, can one assume that the decoded linear pixel values Y_i(p) satisfy an exposure-proportional model in non-saturated regions, such as Y_i(p) ≈ t_i R(p), across brackets? This question is about radiometric consistency for algorithmic use, not about visual editing or tone mapping. Thank you for your help.

At the WWDC26 Camera and Photo Technologies Group Lab (session 8018, ~29:55 to 32:46), the panel explained why ProRAW can produce 48 MP output from Quad Bayer sensors while native Bayer RAW is limited to the binned resolution. ProRAW is already demosaiced and linearized, and may incorporate Photonic Engine multi-frame processing. The native RAW path exposes the binned Bayer result. A true full-resolution RAW output would be Quad Bayer, not conventional Bayer, and supporting it properly needs a decoding path around it. The panel suggested filing Feedback Assistant requests if developers need this, so I filed FB25352517. My use case is computational photography that wants minimally processed sensor-domain samples on purpose — its own multi-frame alignment, denoising, HDR fusion, motion rejection, and super-resolution. Adobe Project Indigo is a public example of that kind of pipeline. It captures RAW bursts and uses measured sub-pixel variation between frames to reconstruct detail. Processed 48 MP photos and ProRAW don't cover that. They've already been through Apple's reconstruction or demosaic. Is filing enhancement requests still the intended path for a supported full-resolution Quad Bayer RAW or mosaic capture path? If so, what would make these reports more useful — mosaic metadata, DNG representation, CIRAWFilter support, AVCaptureDevice.Format capability discovery, something else? WWDC26 session: https://developer.apple.com/videos/play/wwdc2026/8018/ Project Indigo technical overview: https://research.adobe.com/articles/indigo/indigo.html

Whenever I call this method on the PHPhotoLibrary class I get a warning which I've included below. I've tried looking in the Apple forums, Stack Overflow etc. and nobody seems to mention this issue that I can find. Is this warning unavoidable or am I using the API wrong? I can reproduce this trivially in a simple untitled project. Warning: Retain cycle risk: client-side managed object fetch on long-lived context for entity Asset, on context named: PHPhotoLibrary (inode=19657147) .Generic, consider using -[PHPhotoLibrary performAndWaitOnAutoResettingLibraryWithName:workBlock:] or +[PLDatabaseContext newShortLivedLibraryWithName:bundle:]...work, or using a dictionary result type, or suppressing this warning using 'clientSideLongLivedFetchWarningsSuppressed'). STEPS TO REPRODUCE Create a new untitled App project in Xcode. Set a photo library usage privacy description in the Info for the project target Replace ContentView.swift with the code included below. Make sure there is at least one photo in the photo library on the target device. A simulator is fine. Run the app Click the Get Cloud ID button, respond to the authorization dialog Click the Get Cloud ID button again Look in Xcode and see the warning import SwiftUI import Playgrounds import Photos struct ContentView: View { var body: some View { Button( action: getCloudID ) { Text("Get Cloud ID") } .padding() } private func getCloudID() { var fetchOptions = PHFetchOptions() fetchOptions.fetchLimit = 1 let assetResult = PHAsset.fetchAssets(with: .image, options: fetchOptions) var localIds = [String]() assetResult.enumerateObjects() { asset, _, _ in localIds.append(asset.localIdentifier) } let mappings = PHPhotoLibrary.shared().cloudIdentifierMappings(forLocalIdentifiers: localIds ) for mapping in mappings { debugPrint("cloud ID \(mapping.value)") } } } `

For an iPhone recording utility with no calling functionality, what is the supported way to keep the front camera live in Picture in Picture while a ReplayKit broadcast records another foreground app? Is using AVPictureInPictureVideoCallViewController with the voip background mode supported for this purpose?

If a single asset in the array passed to insertOrUpdateAssets cannot be read, the returned AsyncSequence throws and delivers zero elements — including for the valid assets that appear before the offending one in the array. In my measurement a batch of 5 — two valid photographs, one zero-byte .jpg, then two more valid photographs — delivered 0 of 5 elements and reported 0 faces. The framework's own stdout log shows it had already processed the valid photographs before failing, so the work was done and then thrown away. This is the behaviour I would expect from a function returning [Result] after processing everything, not from a streaming AsyncSequence. The whole reason to expose an async sequence is to deliver results as they are produced; here the sequence produces nothing at all, which makes the streaming shape actively misleading. Why this matters at library scale. I am cataloguing 97 photo libraries, many of them archives of scanned family photographs going back to the 1970s, where a handful of damaged files is normal rather than exceptional. As the API stands, the batch size I choose for throughput is also the amount of work a single corrupt file destroys — with a batch of 100, one bad file costs 100 images. The only safe strategy is to catch the failure and re-submit the batch one asset at a time to find the culprit, which turns a rare bad file into a full re-run of that batch and makes the worst case quadratic in the number of bad files. Note also that the error gives no indication of which asset failed (see the related enhancement request on error taxonomy), so isolating the culprit by re-submission is the only option available. Feedback: FB24174733

An image file whose data is cut in half is accepted by insertOrUpdateAssets, produces no error, and is reported as an image containing zero faces. That result is indistinguishable from a photograph that genuinely has no people in it. In my measurement the intact file reported 4 faces and a copy truncated to half its bytes reported 0 faces — both without throwing. Why this is worse than an error. A client that receives "zero faces, no error" will record the asset as analysed, no people present. That is a permanent, silent, incorrect result: the file is never revisited, and the people in it are lost from the catalogue with no diagnostic anywhere. An error would have been recorded as a failure and retried later. Silence is the one outcome that cannot be recovered from. The failure mode is also inconsistent. Other kinds of damaged input do throw — a zero-byte file, a text file with a .jpg extension, and a file whose interior bytes have been destroyed all raise MediaIntelligenceError.faceGroupProcessing. Truncation is the case that silently succeeds, and truncation is precisely the damage that partial downloads, interrupted copies and failing disks produce — the most common form of corruption in a real photo archive, and the one I have to handle in 97 libraries of mixed provenance. My current workaround is to fully decode every image myself before handing it to the framework, purely to detect truncation. That means every file is decoded twice, which roughly doubles the I/O of the analysis pass. Feedback: FB24174749

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.

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 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!

We are developing CameraDirector, an iPhone application that controls external professional cameras through documented vendor APIs and reads back native recording state. We want an AirPods camera-remote press to request record start/stop on the selected external camera, then provide audible confirmation only after the camera reports its state. In external-camera control mode, the app would be in the foreground but would not be capturing video from an iPhone camera. The WWDC25 session 'Enhancing your camera experience with capture controls' states that AVCaptureEventInteraction (or SwiftUI's onCameraCaptureEvent) requires an active AVCaptureSession and does not receive events when the app is backgrounded: https://developer.apple.com/videos/play/wwdc2025/253/ Is there a supported configuration for receiving AirPods capture events in this external-camera mode without running a local iPhone camera capture? Does an active audio-only AVCaptureSession qualify, or does event delivery require an active video-camera input? If this is outside the intended API contract, is there another supported input path for this use case, or should we file an enhancement request? We have not yet established an on-device AirPods result for this configuration. We would appreciate guidance on the intended architecture or a relevant sample and can provide a focused reproducer for an implementation issue. Related capture-event implementation discussion: https://developer.apple.com/forums/thread/740616 Thank you, Eddie DaRoza ACTION Cinema Technologies

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.

Hello Apple Support, I am experiencing a reproducible Continuity Camera issue on my Mac mini M4 running macOS 27. Problem description My iPhone 17 works as a Continuity Camera when a USB webcam is connected to my Mac mini. However, when I disconnect the USB webcam, the iPhone disappears as an available camera from all applications, including FaceTime and OBS. The issue appears to be related to how macOS publishes or registers the Continuity Camera device, rather than the Mac being unable to discover the iPhone. I would like to use my iPhone 17 as a wireless Continuity Camera without having to keep a USB webcam connected. System information Mac: Mac mini M4 Operating system: macOS 27 iPhone: iPhone 17 Third-party application tested: OBS Apple application tested: FaceTime Troubleshooting performed I have already tried the following: Verified that the iPhone is detected by macOS using: system_profiler SPCameraDataType The output lists both devices: WEB CAMER: Model ID: UVC Camera VendorID_19530 ProductID_19029 iPhone 17 Camera: Model ID: iPhone18,3 Unique ID: CA29F0DB-099C-4589-AF19-CE9500000001 Checked the relevant Continuity and camera processes: launchctl list | grep -Ei 'continuity|camera|avconference|cameracapture' The output included: com.apple.mediacontinuityd com.apple.cmio.ContinuityCaptureAgent com.apple.ptpcamerad com.apple.videoconference.camera Inspected the Continuity Capture agent using: launchctl print gui/$(id -u)/com.apple.cmio.ContinuityCaptureAgent The agent was running, with PID 652. Inspected mediacontinuityd. It was initially not running in the user GUI session: state = not running runs = 0 Attempted to restart the Continuity Capture agent: launchctl kickstart -k gui/$(id -u)/com.apple.cmio.ContinuityCaptureAgent macOS returned: Could not kickstart service "com.apple.cmio.ContinuityCaptureAgent": 150: Operation not permitted while System Integrity Protection is engaged Attempted to refresh the Continuity service: launchctl kickstart -k gui/$(id -u)/com.apple.mediacontinuityd The command completed without an error, but the issue remained. Attempted to refresh device discovery: sudo killall -HUP rapportd This did not resolve the issue. Checked for camera helper processes: killall VDCAssistant killall AppleCameraAssistant Neither process was found under my user account. Checked the system logs: log show --last 2m --style compact --predicate 'process == "ContinuityCaptureAgent"' 2>/dev/null | grep -E 'magic:|skip headless|present' | tail -8 The logs repeatedly show that the iPhone is discovered, but its camera is not published. Relevant log messages: Device ... name iPhone 17 present magic:0 (usable:0 nearby:1 wired:0 skipNearByCheck:0) reported magic:0 skip headless device publishing in non magic, non wired state These messages appear repeatedly while the iPhone is detected over Rapport. Restarted the Mac and tested with the USB webcam disconnected. The problem persisted. Tested the iPhone in different physical positions and orientations. This did not resolve the issue. Confirmed that the iPhone disappears from FaceTime and OBS when the USB webcam is disconnected. Expected behaviour The iPhone 17 should remain available as a wireless Continuity Camera when the USB webcam is disconnected. Actual behaviour The iPhone is discovered by the Continuity Capture agent, but the logs show: skip headless device publishing in non magic, non wired state The iPhone camera disappears from all applications when the USB webcam is disconnected. Connecting the USB webcam makes the iPhone camera available again. Questions for Apple Engineering Is this a known issue in macOS 27 affecting Mac mini M4 or other Macs without a built-in camera? What does skip headless device publishing in non magic, non wired state mean in this context? Why does ContinuityCaptureAgent discover the iPhone but refuse to publish it as an available camera? Is there a supported way to refresh or re-register the Continuity Camera service without disabling System Integrity Protection? Is there a known workaround or a planned fix for this issue? I would appreciate help identifying the underlying cause and a permanent solution that allows Continuity Camera to work wirelessly without a USB webcam connected. Thank you.

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.

Question: Camera Permission Reset and NSInternalInconsistencyException on iOS 26 We’ve recently started seeing an issue in our production app: NSInternalInconsistencyException "Call must be made on the main thread" We were able to reproduce the issue by manually revoking/resetting the Camera permission so that its state changes back to notDetermined. This raises a few questions: Does iOS 26 automatically revoke or reset previously granted permissions in certain scenarios? Has Apple introduced any changes to the permission or privacy policy in iOS 26? Is there any known behavior where an existing Camera permission can unexpectedly return to the notDetermined state after an OS update? Has anyone else encountered a similar issue in production after updating to iOS 26? We couldn’t find any clear or recent documentation from Apple that explains a change in this behavior. Has anyone experienced this issue or found any relevant Apple documentation explaining the permission-state changes in iOS 26?