Hi AVFoundation team, I'm seeing a uniform 90° offset in AVCaptureDevice.RotationCoordinator's reported angles between iPhone 17 Pro and iPhone 14 Pro using the front-facing .builtInWideAngleCamera (Center Stage on 17 Pro), and I'd like to confirm whether this is by design and what the recommended consumption pattern is when the rendering surface is an AVSampleBufferDisplayLayer rather than an AVCaptureVideoPreviewLayer. Here is the github repo of sample project. Setup Devices: iPhone 14 Pro (iOS 26.5) and iPhone 17 Pro (iOS 26.4.2) Camera: front, AVCaptureDeviceTypeBuiltInWideAngleCamera Active format: 1920×1080 Three RotationCoordinator instances are created on the same AVCaptureDevice, varying only the previewLayer: argument: - previewLayer: nil - previewLayer: AVSampleBufferDisplayLayer (the surface receiving frames from AVCaptureVideoDataOutput) - previewLayer: AVCaptureVideoPreviewLayer (with .session = captureSession, not displayed) Each instance is KVO-observed for videoRotationAngleForHorizonLevelPreview and videoRotationAngleForHorizonLevelCapture. Observed angles Device / Orientation: 14 Pro · Portrait (interface=1) RC[nil] prev / cap: 0° / 90° RC[AVSampleBufferLayer] prev / cap: 90° / 90° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 90° ──────────────────────────────────────── Device / Orientation: 14 Pro · LandscapeRight (interface=3) RC[nil] prev / cap: 0° / 180° RC[AVSampleBufferLayer] prev / cap: 180° / 180° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 180° ──────────────────────────────────────── Device / Orientation: 17 Pro · Portrait (interface=1) RC[nil] prev / cap: 0° / 0° RC[AVSampleBufferLayer] prev / cap: 0° / 0° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 0° ──────────────────────────────────────── Device / Orientation: 17 Pro · LandscapeRight (interface=3) RC[nil] prev / cap: 0° / 90° RC[AVSampleBufferLayer] prev / cap: 90° / 90° RC[AVCaptureVideoPreviewLayer] prev / cap: 0° / 90° The −90° offset on 17 Pro is uniform: it appears in every RC variant, in both the preview-angle and the capture-angle properties, at every orientation tested. It is not specific to the previewLayer: argument.

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.

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.

let authStatus = PHPhotoLibrary.authorizationStatus(for: .readWrite) let fetchResult = PHAsset.fetchAssets(withLocalIdentifiers: selectedAssetIDs, options: nil) print("[AlbumCreation] authStatus=\(authStatus.rawValue) IDs=\(selectedAssetIDs.count) PHAsset匹配=\(fetchResult.count)") // result is: [AlbumCreation] authStatus=3 IDs=3 PHAsset匹配=3 var config = PHPickerConfiguration(photoLibrary: .shared()) config.preselectedAssetIdentifiers = selectedAssetIDs config.selectionLimit = 0 let picker = PHPickerViewController(configuration: config) picker.delegate = self present(picker, animated: true)

Whilst AVCaptureSession is setup to capture ProRes RAW video, is it possible to get video pixel data which can read and processed, such as using CIImage(cvPixelBuffer: ) AVCaptureVideoDataOutput outputs ProRes RAW in kCVPixelFormatType_96VersatileBayerPacked12 pixel format. Is there a provided way to debayer this pixel format into something more usable?

I'm updating an older Mac app written in Objective C and OpenGL to be a mutliplatform app in SwiftUI and Metal. The app loads images and creates kaleidoscope animations from them. It is a document-based application, and saves info about the kaleidoscope into the document. On macOS, it creates a security-scoped bookmark to remember the user's chosen image. On iOS, I use a PhotosPicker to have the user choose an image from their photo library to use. I would like to get the itemIdentifier from the image they choose and save that into my document so I can use it to fetch the image when the user reloads the kaleidoscope document in the future. However, the call to loadTransferable is returning nil for the itemIdentifier. Here is my iOS/iPadOS code: #if os(macOS) // Mac code #else PhotosPicker("Choose image", selection: $selectedItem, matching: .images) .onChange(of: selectedItem) { Task { if let newValue = selectedItem { scopeState.isHEIC = newValue.supportedContentTypes.contains(UTType.heic) let data = try? await newValue.loadTransferable(type: Data.self) print("newValue = \(newValue)") print("newValue.supportedContentTypes = \(newValue.supportedContentTypes)") scopeState.selectedImageID = newValue.itemIdentifier scopeState.selectedImageData = data } } } #endif The debug print statements show: newValue = PhotosPickerItem(_itemIdentifier: "9386762B-C241-4EE2-9942-BC04017E35C1/L0/001", _shouldExposeItemIdentifier: false, _supportedContentTypes: [<_UTCoreType 0x20098cd40> public.png (not dynamic, declared), <UTType 0x11e4ec060> com.apple.private.photos.thumbnail.standard (not dynamic, declared), <UTType 0x11e4ec150> com.apple.private.photos.thumbnail.low (not dynamic, declared)], _content: _PhotosUI_SwiftUI.PhotosPickerItem.(unknown context at $1e75ee3bc).Content.result(PhotosUI.PHPickerResult(itemProvider: <PUPhotosFileProviderItemProvider: 0x11d2bd680> {types = ( "public.png", "com.apple.private.photos.thumbnail.standard", "com.apple.private.photos.thumbnail.low" )}, _objcResult: <PHPickerResult: 0x11b18cff0>))) newValue.supportedContentTypes = [<_UTCoreType 0x20098cd40> public.png (not dynamic, declared), <UTType 0x11e4ec060> com.apple.private.photos.thumbnail.standard (not dynamic, declared), <UTType 0x11e4ec150> com.apple.private.photos.thumbnail.low (not dynamic, declared)] And the returned item has a nil itemIdentifier. (note the _shouldExposeItemIdentifier=false in the log of the selected item). How do I get the itemIdentifier for the user's chosen image? And is that valid to then fetch the asset when the user reloads their document? Is it like a security-scoped bookmark on macOS, where the itemIdentifier is like a key that gives me permission to reload the image? If not, what do I need to do in order to reload the image the next time the user opens a saved kaleidoscope document?

I'm developing an iOS app that uses Apple's DockKit framework to control gimbals. I've tested with the Insta360 Flow 2 Pro and the DJI Osmo Mobile 8. The Flow 2 Pro supports all DockKit motor control APIs — setAngularVelocity, setOrientation, setLimits — which lets my app do manual pan/tilt control via a virtual joystick. The Osmo Mobile 8 (model DS308, firmware 1.0.0) connects fine via DockKit and reports as docked, but every motor control API fails with "The device doesn't support the requested operation": setAngularVelocity — fails setOrientation(relative: true) — fails setLimits — fails The only thing that works is Apple's system tracking (setSystemTrackingEnabled(true)) for automatic face/body following. This means there's no way for third-party apps to do manual gimbal control (pan/tilt via joystick) on the Osmo 8 through DockKit — only automatic tracking works. Questions: Is anyone else seeing the same limitation with the Osmo 8 and DockKit? Has DJI confirmed whether manual motor control via DockKit is intentionally unsupported, or is this a firmware issue that might be addressed in an update? Does the DJI Mimo app use DockKit for its tracking, or does it use a proprietary Bluetooth protocol? Running iOS 26.4 on iPhone 15 Pro. Happy to share more technical details if helpful.

Somewhere since iOS 26, the LockedCameraCapture framework gets in an unpredictable state after opening the main app from the LockedCamera extension using LockedCameraCaptureSession.openApplication(for userActivity:). (Feedback with sample code to reproduce: FB21966835) Opening the extension from the lock screen again doesn’t open the extension but puts the lock screen in a state as if it has. Content updated from LockedCameraCaptureManager.shared.sessionContentUpdates comes in inconsistently, usually needs the app to be opened again or the extension to be opened. This makes using this extension impossible for me as I use it to record video files that manually need to be imported when the app is launched (so not through PhotoKit). Does anybody have a suggestion to circumvent this issue or how to get this fixed?

I am using iPad Pro M4 device to apply exposure point to the camera. While converting layerPointConverted from 0 -1 range to device size point it is giving wrong value. But if same code is used for other iPad like Gen2, it gives proper value. In both cases video gravity used is resizeAspectFill. I tried using true depth camera for M4 device but it does not work.

This issue affects camera session behavior and UI integration. I would like to request improved support or clarification regarding the simultaneous use of ARFaceTrackingConfiguration and AVCaptureMultiCamSession. Currently, when attempting to use both: Front camera (TrueDepth) for gaze tracking using ARFaceTrackingConfiguration Rear camera for live preview using AVCaptureMultiCamSession the ARKit face tracking stops updating, or the application becomes unstable (e.g., camera preview turns white or the app crashes). Steps to Reproduce: Start ARSession using ARFaceTrackingConfiguration (front camera) Start AVCaptureMultiCamSession using rear camera Overlay both outputs in a single UI Observe that ARKit tracking stops or camera preview becomes invalid Expected Result: ARKit face tracking continues updating while the rear camera is active. Actual Result: ARKit tracking stops updating, and camera output may become unstable or crash. Use Case: This functionality is important for accessibility and educational applications. For example, users can control UI via gaze input (front camera) while observing real-world objects using the rear camera. Request: Support simultaneous use of ARFaceTrackingConfiguration and AVCaptureMultiCamSession, or Improve resource sharing between TrueDepth and rear cameras, or Provide clear documentation about current limitations This feature would significantly enhance accessibility applications on iPad. Attachment: A photo is attached showing the issue on a real iPad device. In the image, the camera preview becomes white while the application is running, indicating unstable behavior when both ARKit face tracking and rear camera capture are active simultaneously.

Feedback: PHBackgroundResourceUploadExtension is never scheduled when iCloud Photos is enabled Summary PHBackgroundResourceUploadExtension's init() and process() methods are never called by the system when iCloud Photos is enabled on the device, even though setUploadJobExtensionEnabled(true) succeeds and uploadJobExtensionEnabled returns true. Environment iOS 26.4 (both devices) Xcode 26.x Tested on iPhone 17 Pro (primary device, 10,000+ photos) and an older iPhone (development device, 200+ photos) Same build deployed to both devices Full photo library access (.authorized) on both devices Steps to Reproduce Create an app with a PHBackgroundResourceUploadExtension (ExtensionKit, extension point com.apple.photos.background-upload) Enable iCloud Photos on the device (Settings > Photos > iCloud Photos) In the host app, request .readWrite photo library authorization and receive .authorized Call PHPhotoLibrary.shared().setUploadJobExtensionEnabled(true) — succeeds without error Verify PHPhotoLibrary.shared().uploadJobExtensionEnabled == true Wait for the system to schedule the extension (tested overnight, with device on charger + WiFi) Expected Behavior The system should call the extension's init() and process() methods to allow the app to create upload jobs, as documented in "Uploading asset resources in the background." Actual Behavior The extension's init() and process() are never called. The extension process is never launched. Investigation via Console.app Using Console.app to monitor system logs on both devices revealed the root cause: When iCloud Photos is DISABLED (extension works correctly): assetsd Checked all submitted library bundles. Result: YES dasd SUBMITTING: com.apple.assetsd.backgroundjobservice.assetresourceuploadextensionrunner:35E7B5 dasd Submitted: ...assetresourceuploadextensionrunner at priority 5 dasd submitTaskRequestWithIdentifier: Submitted BGSystemTask com.apple.assetsd.backgroundjobservice.assetresourceuploadextensionrunner The extension is subsequently launched and init() / process() are called as expected. When iCloud Photos is ENABLED (extension never works): assetsd Checked all submitted library bundles. Result: NO No assetresourceuploadextensionrunner background task is ever submitted to dasd. The extension is never launched. Reproducibility 100% reproducible across two different devices Toggling iCloud Photos off (and waiting for sync to complete) immediately resolves the issue Toggling iCloud Photos on immediately causes the issue to reappear Reinstalling the app does not help The same build works on the same device when iCloud Photos is disabled Impact This effectively makes PHBackgroundResourceUploadExtension unusable for the vast majority of users, as most iPhone users have iCloud Photos enabled. Third-party photo backup apps (Google Photos, Dropbox, OneDrive, etc.) would all be affected by this limitation. The documentation for "Uploading asset resources in the background" does not mention any incompatibility with iCloud Photos being enabled. Requested Resolution Please either: Allow PHBackgroundResourceUploadExtension to be scheduled regardless of iCloud Photos status, or Document this limitation clearly in the API documentation if it is intentional behavior

While working on a heart rate measurement app (photoplethysmography via camera), we faced systematic err=-17281 (FigCaptureSourceRemote) issues on real devices starting from iOS 17+, and the problem became more noticeable after iOS 26. The error often appeared during AVCaptureSession initialization or when restarting capture, especially under high frame rates (30-60 FPS) and frequent foreground/background transitions. Root cause (our understanding): Camera hardware/session not fully released after previous use Race conditions between session teardown and new setup Changes in AVFoundation capture pipeline in recent iOS versions Our solution: Instead of blocking delays, we implemented asynchronous retry logic with explicit hardware readiness check via AVCaptureDevice.lockForConfiguration().

Hi, I'm investigating whether 18MP photo capture from the front camera on iPhone 17 Pro is available to third-party apps using AVFoundation. I first inspected all available AVCaptureDevice formats, but I could not find any format corresponding to ~18MP resolution (e.g., around 4896×3672). for format in device.formats { let desc = format.formatDescription let dims = CMVideoFormatDescriptionGetDimensions(desc) print("Format: (dims.width) x (dims.height)") } All reported formats appear to be limited to resolutions such as 4032×3024 (12MP) or below. Question: Is 18MP front camera capture actually available to third-party apps via AVFoundation on iPhone 17?

I just submitted FB22318443. In Mac Catalyst apps running on macOS 26.4, if you choose to limit the app's access to specific photos (as opposed to granting full access), the photos do not appear in the app. 💀 This issue does not occur on iPadOS. It is a macOS 26.4 regression. It occurs even with apps built using a previous version of the SDK such as 26.2. A sample of the console logs: [RM]: 4-1-1 failed to decode for asset: 9290CC20-B85D-47B5-BDBE-D330FE61773D, error code: 3303, description: Error Domain=PHPhotosErrorDomain Code=3303 "(null)" Failed to get sandbox extension for url: file:///Users/Jordan/Pictures/Photos%20Library.photoslibrary/resources/derivatives/masters/9/9290CC20-B85D-47B5-BDBE-D330FE61773D_4_5005_c.jpeg, error: Error Domain=com.apple.photos.error Code=44001 "sandbox extension not in the cache after requesting them for path: /Users/Jordan/Pictures/Photos Library.photoslibrary/resources/derivatives/masters/9/9290CC20-B85D-47B5-BDBE-D330FE61773D_4_5005_c.jpeg" UserInfo={NSDebugDescription=sandbox extension not in the cache after requesting them for path: /Users/Jordan/Pictures/Photos Library.photoslibrary/resources/derivatives/masters/9/9290CC20-B85D-47B5-BDBE-D330FE61773D_4_5005_c.jpeg} [RM]: 1-1-1 Image request failed with error: Error Domain=PHPhotosErrorDomain Code=3303 "(null)"

I'm developing a PHBackgroundResourceUploadExtension and finding it difficult to debug because the system controls when the extension launches. Current experience: The extension starts at unpredictable times (anywhere from 1 minute to several hours after photos are added) By the time I attach the debugger, the upload may have already completed or failed Breakpoints in init() or early lifecycle methods are often missed Questions: Is there a way to force-launch the extension during development (similar to how we can manually trigger Background App Refresh in Xcode)? Are there any launch arguments or environment variables that put the extension in a debug/eager mode? I tried taking photos/videos, but this doesn't trigged app extension in all cases. Any tips for improving the debug cycle would be greatly appreciated. Environment: iOS 26, Xcode 18

I'm implementing a PHBackgroundResourceUploadExtension to back up photos and videos from the user's library to our cloud storage service. Our existing upload infrastructure uses chunked uploads for large files (splitting videos into smaller byte ranges and uploading each chunk separately). This approach: Allows resumable uploads if interrupted Stays within server-side request size limits Provides granular progress tracking Looking at the PHAssetResourceUploadJobChangeRequest.createJob(destination:resource:) API, I don't see a way to specify byte ranges or create multiple jobs for chunks of the same resource. Questions: Does the system handle large files (1GB+) automatically under the hood, or is there a recommended maximum file size for a single upload job? Is there a supported pattern for chunked/resumable uploads, or should the destination URL endpoint handle the entire file in one request? If our server requires chunked uploads (e.g., BITS protocol with CreateSession → Fragment → CloseSession), is this extension the right mechanism, or should we use a different approach for large videos? Any guidance on best practices for large asset uploads would be greatly appreciated. Environment: iOS 26, Xcode 18

Hi everyone, I’m seeing recurring internal AVFoundation camera logs on iOS 26.2 and I’m trying to understand whether this is expected behavior or a regression in the capture pipeline. These logs appear shortly after starting an AVCaptureSession, while video frames are being delivered, and also when the camera is stopped or the capture session is torn down. <<<< FigXPCUtilities >>>> signalled err=-17281 at <>:302 <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:569) - (err=-17281) Even in this clean, minimal setup, the same logs appear on iOS 26.2 The exact same logic did not produce these logs on iOS 18.x. To rule out issues caused by my own code, GPT created a minimal SwiftUI example from scratch. My primary interest is to perform real-time processing on the video frames delivered by the camera (via AVCaptureVideoDataOutput), for tasks such as analysis, computer vision, or custom frame handling, while simultaneously displaying the live preview. Thanks in advance for any insight. Example Code

I'm implementing PHBackgroundResourceUploadExtension to back up photos and videos to our cloud storage service. During testing, I observed that iCloud-optimized photos (where the full-resolution original is stored in iCloud, not on device) do not upload. The upload job appears to silently skip these assets. Questions: Is this behavior intentional/documented? I couldn't find explicit mention of this limitation. If the device only has the optimized/thumbnail version locally, does the system: - Automatically download the full-resolution asset from iCloud before uploading? - Skip the asset entirely? - Return an error via PHAssetResourceUploadJobChangeRequest? For a complete backup solution, should we: - Pre-fetch full-resolution assets using PHAssetResourceManager.requestData(for:options:) before creating upload jobs? - Use a hybrid approach (this extension for local assets + separate logic for iCloud-only assets)? Environment: iOS 26, Xcode 18

How I can get iCloud photo file size? Could I use private API like this in prod? Does anyone know another way? (without downloading the file to the device) func getFileSize(asset: PHAsset) -> Int64? { let resources = PHAssetResource.assetResources(for: asset) let resource = resources.first let size = resource?.value(forKey: "fileSize") as? Int64 return size }

Hi, I am trying to implement a PHBackgroundResourceUploadExtension to upload backup media files to an external cloud service based on these docs: https://developer.apple.com/documentation/PhotoKit/uploading-asset-resources-in-the-background#Acknowledge-completed-jobs Creating jobs and actual uploading is working as expected, but the problem I have is in the acknowledgeCompletedJobs() function. When trying to access a job's resource, the resource is nil and thus has empty assetLocalIdentifier and originalFilename. Did anybody successfully implement this extension or knows, why this would happen? Because the resource of an acknowledgable job is empty, I can not match it back to my processed assets.