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

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 am requesting technical clarification and a formal feature addition regarding the availability of per-frame calibration data for Standard RAW captures on iPhone 17 and 17 Pro. The Technical Gap: Currently, AVCaptureVideoDataOutput provides a direct path to the AVCameraCalibrationData object, allowing real-time access to the Intrinsic Matrix, Radial/Tangential Distortion coefficients, and Lens Shading Maps. However, this same level of geometric transparency is missing from the AVCapturePhoto RAW/ProRAW delegate. While standard RAW files contain some metadata, they lack the physics sidecar required for precision manual alignment. Because the lens assembly in the iPhone 17 Pro is dynamic shifted constantly by Optical Image Stabilization (OIS) and high-speed Voice Coil Motors (VCM) for focus a static or factor calibration is mathematically insufficient for high-precision workflows. The Problem: Without the 1:1 hardware state at the millisecond of exposure, we cannot perform accurate geometric reconstruction from RAW stills. We are forced to choose between the high dynamic range of a RAW sensor dump and the geometric precision of the video pipeline. Final Questions: Is there a documented, supported method to force the inclusion of the AVCameraCalibrationData object or a raw metadata sidecar in the AVCapturePhoto workflow? If not, can Apple provide parity between the Video and Photo APIs so that the "rawest" data (RAW) is accompanied by the "rawest" physics (Calibration Data)? Providing the pixels without the lens geometry limits the utility of the RAW format for any technical workflow requiring sub-pixel geometric integrity.

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.

Hello, Starting in iOS 17, our application started having some issue publishing to our video session. More specifically the video capture seems to be broken in some, but not all sessions. What's troubling is that we're seeing that it fails consistently every 4 sessions. It also fails silently, without reporting any problems to the app. We only notice that there are no frames being rendered or sent to the remote devices. Here's what shows-up in the console: <<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail (FigCaptureSourceRemote.m:235) - (err=0) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:253) - (err=-16453) Anyone seeing this? Any idea what could be the cause? Our sessions work perfectly on iOS16 and below. Thanks

Thanks for your great questions. We'll be wrapping up our live feedback session in 15 minutes. Please get your questions in soon.

What is the intended purpose of the new PHPhotoLibraryPersistentChangesObserver? I currently use PHPhotoLibraryChangeObserver as a trigger, then call fetchPersistentChanges(since:). What behavior or guarantees differ when using PHPhotoLibraryPersistentChangesObserver instead? Thanks!

For a PHAsset in the same Photos library on the same device/Mac, what are the documented stability guarantees of PHObject.localIdentifier? Is it safe to persist and use for future PhotoKit operations in that same local library? Are there known cases where it can change or stop resolving? If a persisted localIdentifier no longer resolves but a persisted PHCloudIdentifier.archivalStringValue does resolve in the same library, is updating the stored local identifier from that cloud mapping the recommended recovery path? Thanks!

My app displays photos from user's photo library. I want to provide a way to deep link to that photo in the Photos app (open the photo in the Photos app). Is there any way to do this?

I saw that the Broadcast extension is deprecated in iOS 28, as well as the ReplayKit with nothing mentioned on what is going to be used going forward. I found out that the Screen Capture Kit is mentioned as replacement but is available for macOS only, even though some methods now are marked with iOS 28+ (https://developer.apple.com/documentation/screencapturekit). Will the ScreenCaptureKit be used for screen sharing going forward and replace the Broadcast Extension?

Is there a supported way for developers to purge locally downloaded Photos originals/resources in order to force an asset/resource into a non-downloaded iCloud-only state? Basically simulate "Optimize Mac Storage" behavior on demand for testing. Thanks!

Is there a way to determine whether a specific PHAssetResource original is locally available/downloaded without requesting it? If not, is the recommended approach to request the resource with PHAssetResourceRequestOptions.isNetworkAccessAllowed = false and handle networkAccessRequired error? Is that error the definitive signal that the requested resource is not locally available, or are there other errors that should be treated the same way? Thanks!

Can Photos.framework distinguish between assets that are stored in the user’s Personal Library and assets that are stored in the Shared Library? If not, is there a planned API that would allow developers to identify the library membership of a PHAsset?

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().

In Apple's Camera app (set to "Photo" mode), when the system switches between different cameras, the transition is incredibly smooth. In particular, when getting too close to an object for the wide angle camera (due to the minimal focus distance), it automatically switches to the ultra-wide angle. When switching, the app transitions between the cameras very smoothly, by which I mean the position of the object in frame doesn't shift despite the physical location of the cameras being different. Is it possible to replicate this behaviour with the AVFoundation API? When creating a AVCaptureSession using a AVCaptureDevice with the builtInTripleCamera device type, the session automatically switches between the constituent cameras as expected. However, unlike Apple's Camera app, there is a very noticeable shift in perspective when switching. This is especially noticeable when switching between the WA and UWA cameras while zoomed in, sometimes resulting in the center of the frame being shifted all the way to the edge of the screen. I was able to somewhat replicate the smooth switching by setting activeVideoStabilizationMode of my AVCaptureConnection (with AVCaptureVideoDataOutput) to .cinematic, but this would introduce too much delay for a live preview, and none of the other available stabilization modes seemed to support this smooth transitioning. Is it possible to replicate the behaviour of the Camera app using the AVFoundation API?

I would like to request a linear scene-referred preview stream for Bayer RAW workflows via AVCaptureVideoDataOutput or AVCaptureVideoPreviewLayer, without tone mapping, computational processing, or a baked-in rendered look. This is particularly important for third-party camera apps built around Bayer RAW workflows, including my app, Lampa Camera. In other words, it would be great to have a preview mode that closely matches the CIRAWFilter output for a Bayer DNG with the following configuration: rawFilter.baselineExposure = 0.0 rawFilter.shadowBias = 0.0 rawFilter.boostAmount = 0.0 rawFilter.localToneMapAmount = 0.0 Currently, the live preview comes from the processed camera feed. As a result, the viewfinder can differ noticeably from the final RAW-converted image in exposure, dynamic range, contrast, and sharpness. A Bayer RAW-compatible linear preview mode would make it possible to provide a reliable what-you-see-is-what-you-get shooting experience for RAW-based camera apps. Would Apple consider exposing such a preview mode in AVFoundation? Related Feedback Assistant report: FB22660803

In a multi-frame 360° stitching pipeline with ARKit, what's the recommended way to lock exposure and white balance consistently across frames, and is AVFoundation-first better than ARKit-first for this?

After taking a screenshot, click the picture to crop and save it. Only the uncropped content will be displayed, not the cropped content.

PHAsset.mediaSubtypes.contains(.photoDepthEffect) exposes the portrait/depth-effect flag through PhotoKit. Is there a way to detect the same Photos “Portrait” classification when reading the image file directly using ImageIO? I've found that key 25 in kCGImagePropertyMakerAppleDictionary appears to correlate with the Portrait flag. Is the existence of this key a stable signal for that classification, or should I use another ImageIO signal? Thanks!

Is there a way to get AI metadata from photokit without having to run the algorithms again? I'd like to be able to get captions, featureprint, and optimal crops. I can use Vision and CoreML to generate these, but it'd be easier/better to read the info directly from Photokit.