I want to report a issue on PHAssetChangeRequest.deleteAssets Environment iOS 18.5, iOS 26.2.5, iOS 27.0 Steps to Reproduce Capture a 48MP ProRAW (DNG) photo with the Camera app. Open my app, call the following api to delete this photo: PHPhotoLibrary.shared().performChanges({ PHAssetChangeRequest.deleteAssets(assets) }, completionHandler: completionHandler) Expected The system delete-confirmation dialog appears; after the user confirms, the asset is deleted and the completionHandler is called or report error if it failed Actual Sometime the following issue happens: The confirmation dialog never appears and the completionHandler is never called no success, no error, no timeout. The built-in Photos app can delete the affected asset but API can't. The stuck request leaks permanently. Even after the same asset is subsequently deleted via the built-in Photos app, the pending completionHandler is still never invoked. Workaround for this issue When the issue happens, restarting the iPhone or reinstall app can not help to fix it But I found if I leave the device alone for an extended period (maybe 10 min~1 hour) and restart the iPhone, finally I found PHAssetChangeRequest.deleteAssets work again. It looks like some background task for 48MP RAW image in DNG format stuck delete API. I need to wait the task finished and restart device to reset stuck status. But I can not know when the DNG is ready to delete, it looks like my app hangs I think the better behavior is completion block should return a error to tell user what happens instead of not calling completion block.

Good Evening, I have some old code that uses the CameraFrameProvider successfully when run through Xcode versions 26.0 and 26.2, but not for 26.6. I have double checked all Custom iOS Target Properties in the project's info tab to make sure all required capabilities are added. I also updated the enterprise license by adding a new entitlements file approving main-camera-access. Somewhere between Xcode 26.2 and Xcode 26.6 what has changed that affects the ability to use CameraFrameProvider and access the Main Camera? Thank you.

I previously reported an issue where PHImageManager.requestImageDataAndOrientation() never calls its progress or completion handler. In this thread, it was mentioned that iOS 27 beta 3 fixes a PhotoKit hang involving the deletion of recently captured 48 MP ProRAW assets. I know these involve different APIs (PHPhotoLibrary and PHImageManager). But the behavior looks the same. The request hangs without ever calling back, and later PhotoKit requests get stuck as well. Will the PHImageManager issue I reported also be fixed when iOS 27 is officially released?

Starting with iOS 26.6, saving an image to the photo library via PHAssetCreationRequest.addResource(with: .photo, data:, options:) appears to re-encode the image, dropping all EXIF metadata. The same code preserved metadata through iOS 26.5. let creationRequest = PHAssetCreationRequest.forAsset() creationRequest.addResource(with: .photo, data: image, options: nil) I would like to know whether this change is intentional, and whether the file-based overload is the supported way to preserve an image's original metadata. What we verified The bytes we hand to PhotoKit still contain the metadata. Setting contentType explicitly does not help. We resolved the type from the data and confirmed at runtime that it was non-nil (public.jpeg): let options = PHAssetResourceCreationOptions() if #available(iOS 26.0, *) { options.contentType = contentType // verified: UTType.jpeg, not nil } let request = PHAssetCreationRequest.forAsset() request.addResource(with: .photo, data: imageData, options: options) The resulting asset still has no EXIF. Writing the identical bytes to a temporary file and using the file-based overload preserves everything: try imageData.write(to: temporaryFileURL, options: .atomic) let options = PHAssetResourceCreationOptions() options.shouldMoveFile = true let request = PHAssetCreationRequest.forAsset() request.addResource(with: .photo, fileURL: temporaryFileURL, options: options) Capture date, camera information and location are all intact. We access the library with PHAccessLevel.addOnly.

On iOS 26.6.2, Live Photos fail to save. This issue does not occur on iOS 27.0 RC. Devices Experiencing Issues iPhone 17 (iOS 26.6.2) iPhone 17 Pro MAX(iOS 26.6.2) iPad mini 5th generation (iPadOS 26.6.2) and might be others... Description 1. For HEVC+MOV, the Livephoto is saved successfully. If you write the code exactly as shown in the official instruction the Live Photo will be saved successfully. However, the reference code uses a combination of HEVC and MOV. let photoSettings = AVCapturePhotoSettings(format: [AVVideoCodecKey: AVVideoCodecType.hevc]) 2. For JPEG+MOV, Livephoto saving fails. Some users prefer JPEG files, which offer high compatibility. Therefore, we'll modify the code as follows. let photoSettings = AVCapturePhotoSettings(format: [AVVideoCodecKey: AVVideoCodecType.jpeg]) In this case, the AVFoundation recording process itself succeeds, but when attempting to save the result to the photo library using PhotoKit, it fails with the following error. error:The operation couldn’t be completed. (PHPhotosErrorDomain error 3302.) key: __NSCFString = "_PHResourceUrlsErrorKey" Here is the code for saving Live Photos. (This is exactly the same as the code in the official reference.) PHPhotoLibrary.shared().performChanges({ let creationRequest = PHAssetCreationRequest.forAsset() creationRequest.addResource(with: .photo, data: stillImageData, options: nil) let options = PHAssetResourceCreationOptions() options.shouldMoveFile = true creationRequest.addResource(with: .pairedVideo, fileURL: livePhotoMovieURL, options: options) }) { success, error in // Handle completion. } We've posted to Apple Feedback with Sysdiagnose. FB24760461

In my app, I use api provided in Photos framework to delete specified photo. But after upgrading to iOS 26, the delete function in some iOS device no longer work. The api will never triggers the system confirmation dialog, and the completionHandler is never called. In the iOS Photos app, deletion works correctly on the same assets, but calling the API from my app does not work. Steps to Reproduce Make sure the app has Full Photo Library Access. Execute the following code: PHPhotoLibrary.shared().performChanges({ let assetsToBeDeleted = PHAsset.fetchAssets(withLocalIdentifiers: delUrls, options: nil) PHAssetChangeRequest.deleteAssets(assetsToBeDeleted) }, completionHandler: completionHandler) Expected Behavior The system should present a confirmation dialog asking the user to delete the selected photos. After the user confirms, the deletion should occur, and the completionHandler should be called with success or error. Actual Behavior The system delete confirmation dialog does not appear. The completionHandler is never called. Environment iOS Versions: 26.1 / 26.0.1 It looks like api bug. I want to check Is it a know issue and will be fixed. Thanks

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?

My app is built with Xcode 26.1 and uses a customized photo picker implemented with the PhotoKit Framework. After saving an image attached in the Gmail app to the Photos app on iOS 26.6.1 or iOS 26.6.2, when my app selects and loads that image, the Exif XResolution and YResolution values are both reported as 0. Is this an iOS bug? The following code retrieves the XResolution and YResolution values from the PHAsset of the selected image. private func selectAsset(_ asset: PHAsset) { let options = PHImageRequestOptions() options.isNetworkAccessAllowed = true options.deliveryMode = .highQualityFormat PHImageManager.default().requestImageDataAndOrientation(for: asset, options: options) { data, _, _, _ in DispatchQueue.main.async { if let data { let options = PHImageRequestOptions() options.isNetworkAccessAllowed = true options.deliveryMode = .highQualityFormat PHImageManager.default().requestImageDataAndOrientation(for: asset, options: options) { data, _, _, _ in guard let data, let source = CGImageSourceCreateWithData(data as CFData, nil), let properties = CGImageSourceCopyPropertiesAtIndex(source, 0, nil) as? [CFString: Any], let tiff = properties[kCGImagePropertyTIFFDictionary] as? [CFString: Any] else { print("XResolution: NaN, YResolution: NaN") return } let xResolution = tiff[kCGImagePropertyTIFFXResolution] as? Double let yResolution = tiff[kCGImagePropertyTIFFYResolution] as? Double print("XResolution: \(xResolution.map { String($0) } ?? "NaN"), YResolution: \(yResolution.map { String($0) } ?? "NaN")") } } } } } Result on iOS 26.6 XResolution: 72, YResolution: 72 Result on iOS 26.6.1 and 26.6.2 XResolution: 0, YResolution: 0

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?

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?

In the WWDC talk: https://developer.apple.com/videos/play/wwdc2026/305/?time=350 "Enhance RAW image processing with Core Image" there is a section on the new RAW9 processing APIs and how to enable them. First off, the sample code compiles on iOS18 but causes a runtime exception because the .version9 symbol cannot be found, looks like the header definition is missing a version check for this value, so I'm not sure how to use this code if you need to support iOS18. Also on later dev betas (I tried the latest beta7) now trying to check if version9 is available the value is no longer present in the supported list: guard filter.supportedDecoderVersions.contains(.version9) else { ... There is another value .version9DNG that resolves to true but if I try to use that decoder the colors on the RAW image are wrong and the image becomes corrupted. How to use the RAW9 decoder in the latest dev betas, what should the final code before production because the WWDC sample now seems out of date and was always wrong wrt. iOS18.

Are color differences expected for any cameras? I have heard some reports, but have not seen it myself. If it's not expected, then I can get those people to file bugs.

On every iOS 27.0 beta, setExposureModeCustom has no effect on the front camera (.builtInTrueDepthCamera). exposureMode does change to .custom, but the sensor keeps auto-exposing: device.iso and device.exposureDuration report auto-exposure's values, not the requested ones, and frame brightness does not change. No error is thrown. The same code works on iOS 18.x and 26.x on the same devices. Device: iPhone 15 Pro, every iOS 27.0 beta. Also seen on iPhone 14 Pro Max, 16, 16 Pro Max and 17 Pro Max. Session: front camera, AVCaptureVideoDataOutput (BGRA) + AVCaptureDepthDataOutput. Format advertises ISO 20...1920, duration 0.00004...0.06667 s. isExposureModeSupported(.custom) is true. Repro: let auto-exposure settle, then try device.lockForConfiguration() device.setExposureModeCustom(duration: CMTime(value: 1, timescale: 15), iso: 1920, completionHandler: nil) device.unlockForConfiguration() then poll device.iso / device.exposureDuration (the completion handler never fires on this device) and measure frame luma. Readback, polled 0.8 s after the call: requested ISO 1920, 66.7 ms -> reported ISO 349, 60.0 ms requested ISO 20, 0.04 ms -> reported ISO 188, 66.5 ms Requesting the shortest exposure returns the longest, and the same ISO 1920 request returned 249, 349 and 450 on three consecutive runs, so these are auto-exposure's values. Frame luma stayed within 1% between the two phases. setExposureTargetBias, however, is honored on the same device: at +4 EV auto-exposure drives the sensor to ISO 1920 / 66.5 ms and at -4 EV to ISO 24 / 30.0 ms, moving mean luma from 49 to 232. So the sensor does reach the values setExposureModeCustom cannot set. Question: is this intentional or a regression, and how should an app detect that a custom exposure request was refused?

I save stills and videos with PHAssetCreationRequest. I do not set originalFilename. Photos saved with addResource(with: .photo, data:) show originalFilename values like IMG_XXXX.HEIC in PHAssetResource. Videos saved with addResource(with: .video, fileURL:) from AVCaptureMovieFileOutput keep the temp file name (a UUID .mov). The docs say that if originalFilename is omitted, Photos infers a name from the file URL when one is provided, otherwise it generates a name. Is there a supported way for a third-party app to get a system IMG_XXXX original filename for a newly saved video? Thank you.

In the old simulator you were able to simply drag a photo or video from your desktop into the photos app within the simulator in order to use it for testing. That doesn't seem to be working yet in Device Hub. Is there a workaround or are we just waiting on this to be fixed?

The iOS 27 SDK newly exposed PHLivePhotoRequestOptions.preferHDR. Its documentation states: For best results, only enable this when you intend to display an HDR experience in PHLivePhotoView — for example, when the view’s preferredImageDynamicRange is greater than standard (SDR). PHLivePhotoView has no preferredImageDynamicRange property. How is this API to be used then?

On every iOS 27.0 beta, setExposureModeCustom(duration:iso:completionHandler:) on the front TrueDepth camera (.builtInTrueDepthCamera, position .front) no longer has any observable effect on the video stream. Frame brightness continues to track continuous auto exposure. The same code applies exposure correctly on iOS 26.x and iOS 18.x on the same devices. Reproduced on iPhone 14 Pro Max, iPhone 16, iPhone 16 Pro Max, and iPhone 17 Pro Max running iOS 27.0 betas. Not reproducible on any earlier iOS on the same hardware. Configuration: AVCaptureSession with the TrueDepth device as video input AVCaptureVideoDataOutput (BGRA) plus AVCaptureDepthDataOutput connected Session running, auto exposure settled Repro: Start the session above and wait ~2 s for AE to settle. Apply a custom exposure that should visibly overexpose the image: try device.lockForConfiguration() let format = device.activeFormat device.setExposureModeCustom( duration: CMTime(value: 1, timescale: 15), iso: format.maxISO, // device reports ISO ran completionHandler: nil ) device.unlockForConfiguration() Observe mean luma of delivered frames. Expected: frames become heavily overexposed (max ISO at 1/15 s). Actual: frame brightness is unchanged and keeps adapting with call never happened. No error is thrown, lockForConfiguration succeeds, and isExposureModeSupported(.custom) returns true. The device als custom range (ISO 20...1920, duration up to 1/15 s), so there is no API-visible signal that the command was not applied. [READBACK RESULT: state her device.exposureMode / device.iso / device.exposureDuration reflect the requested values after the call.] Possibly related: on earlier releases the completionHandler f fired on builtInTrueDepthCamera (https://developer.apple.com/forums/thread/770566), while the exposure values themselves were still applied. On i longer applied either. Questions: Is this an intentional change (for example, the system ret while the TrueDepth/depth pipeline is active), or a regression? If intentional, what is the supported way for an app to de refused, and is custom exposure still possible while an AVCaptureDepthDataOutput is connected?

I’m seeing a repeatable first-party cameracaptured crash on an iPhone 14 Pro (iPhone15,2) running iOS 27 beta 5 (24A5424a). The single-camera AVCaptureSession configuration is: Front wide camera 3840×2160 at 30 fps, SDR/420f Two AVCaptureVideoDataOutput connections: Main recording output: 3840×2160 Auxiliary preview output: approximately 2096×1178 Both connections request and activate .standard video stabilization Within roughly two minutes, cameracaptured crashed three times—once during recording and twice during idle preview. The application receives AVErrorMediaServicesWereReset (-11819) after each crash. All three reports have the same faulting queue and underlying stack: com.apple.coremedia.capture.videodata-stabilization.front FigCFDictionaryGetCGRectIfPresent -[BWVISNode _transformRectanglesInMetadata:pts:] -[BWVISNode _stabilizeMetadataForSampleBuffer:] -[BWVISNode _tallyAndEmitSampleBuffer:] VideoStabilizationV2 The first two crashes are: EXC_BAD_ACCESS / EXC_ARM_PAC_FAIL address: 0x00000000dac11a30 termination: PAC_EXCEPTION, code 261 The third reaches the same stabilization stack but terminates with: EXC_BAD_ACCESS / SIGSEGV KERN_INVALID_ADDRESS at 0x30 App-side frame analytics were disabled, system pressure remained nominal, and neither audiomxd nor bluetoothd restarted. The first crash report also shows two front- stabilization worker threads, consistent with the two stabilized video outputs. I have filed Feedback Assistant report FB24553011 with the complete log archive and all three cameracaptured reports. With the iOS 27 public release approaching, waiting for an OS-side fix is not a viable shipping strategy; an app-side workaround is effectively the only option available for our release. Is this a known issue? In particular: Is it safe to leave .standard stabilization on the main recording connection while forcing the auxiliary preview connection to .off? Would disabling/removing the auxiliary AVCaptureVideoDataOutput reliably reduce this to one stabilization pipeline? If a single stabilized front output remains affected, is disabling front-camera stabilization entirely the only supported containment? Is there any public API for disabling the rectangle-metadata processing performed by BWVISNode? The current field workaround is to use the front camera with stabilization Off, or use a rear camera when stabilization is required.

In WWDC20 it was mentioned that missing compileTime/renderTime (or no intermediate image with the dump-intermediates option) can indicate a cached intermediate. I have also seen renderTime=cacheHit on passes that are clearly rendering intermediates, and an actual renderTime is only properly shown on the final pass which always seems to equal the final time render time. In compileTime it says cacheMiss. Which fields should be considered authoritative for tracking intermediate cache hits versus actual rendering? Thanks!