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

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.

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!

While developing a gallery app, I noticed that the iCloudId can change between devices Phone1 and Phone2, on which iCloud is active. First, I know the assetId is unstable, but the iCloud ID ( How it can be? I thought it was stable and I could use it for sending, for example as a UUID for a items on BE to prevent duplication. Could you please explain to me in which cases the iCloudId can change, and what I can use for stable UUID for my internal item to prevent duplication on the BE side? Additional info: Phone1: - assetId part = B01B27D9-10BE-4C95-BE35-C9A03DBA4006 - iCloudId part = 39E0E3A6-6A37-4E8E-83E9-C1B837E2E973 - iCloudId full = 39E0E3A6-6A37-4E8E-83E9-C1B837E2E973:001:ARUcJ2AQQ/nM6BIRu2dq/NSPi61u Phone2: - assetId part = F51B272C-1BE6-41B3-AB54-39E6BDE1C984 - iCloudId part = F51B272C-1BE6-41B3-AB54-39E6BDE1C984 - iCloudId full = F51B272C-1 BE6-41B3-AB54-39E6BDE1C984:001:ARUcJ2AQQ/mM6BIRu2dq/NSPi61u

When building apps, how can I maximize my camera features while using an app to scan and analyze textiles? Is there an integration that has to be inputted that catalogs every fabric type or AI models are able to learn fabric type from every scan? also what is the process/code of including visionOS to scan fabric types to catalog on devices such as smartphones and computers?

I’m seeing a device/OS-specific AVFoundation issue on iPhone 14 Pro running iOS 26.6. A secondary AVCaptureVideoDataOutput is used to provide an unstabilized monitoring feed while the main recording connection is stabilized. During continuous zoom changes, frames from the secondary output continue arriving and scene motion remains live, but its visible zoom/crop/FOV intermittently remains unchanged and then catches up. The saved recording remains smooth and reflects the requested zoom correctly. Minimal configuration: Device: iPhone 14 Pro iOS: 26.6 Physical Ultra Wide camera 1920×1080 at 30 fps SDR, 8-bit YUV Main VDO: 420v Main connection stabilization: .cinematicExtendedEnhanced Auxiliary VDO: 420f Auxiliary connection stabilization: explicitly .off automaticallyConfiguresOutputBufferDimensions = false deliversPreviewSizedOutputBuffers = true alwaysDiscardsLateVideoFrames = true Deferred start disabled Both outputs use a serial delegate queue The auxiliary output is displayed directly without image processing. During continuous videoZoomFactor updates: AVCaptureDevice.videoZoomFactor advances correctly. The UI zoom value advances correctly. The main recorded output zooms smoothly. Frames from the auxiliary output continue arriving and scene motion remains live. Only the auxiliary output's visible zoom/crop/FOV intermittently holds at an older value and then catches up. This is not a complete preview-frame stall: camera movement remains visible during the periods when zoom does not visually advance. The problem occurs with any non-Off stabilization tier in the production app because that configuration installs the unstabilized auxiliary output. Stabilization Off removes the auxiliary topology, and zoom then appears smooth on the main preview feed. A standalone capture sample reproduces the problem without the application’s writer or rendering pipeline. Current device matrix: iPhone 14 Pro, iOS 26.6: reproduces. iPhone 13 Pro, iOS 18.6.x, same released application version: does not reproduce. iPhone 17 Pro, iOS 26.6, isolated sample: does not reproduce. iPhone 14 Pro, iOS 27 beta 5: testing in progress — result to be added. The issue was initially reported with HEVC/Apple Log capture, but it remains reproducible after reducing the graph to 1080p30 SDR8. Questions: Is using two video-data-output connections with different stabilization modes—Extreme on the recording output and Off on the monitoring output—a supported configuration? Is delayed propagation of zoom geometry/crop to a secondary video-data output known on iPhone 14 Pro/iOS 26 when another output connection is stabilized? Is there a recommended AVFoundation topology for obtaining a low-latency, unstabilized monitoring feed while separately recording stabilized video? Are there output or connection properties that must be set to make videoZoomFactor geometry changes propagate synchronously to both outputs? I can provide the standalone sample project, screen recordings, connection-mode logs, buffer PTS/arrival cadence, and a sysdiagnose. EDIT: Issue seen on iOS 27 beta 5 devices as well. No such issue is seen in iOS 18 devices.

PHAssetExtendedMetadata has the following API: /// The original file name of this asset. open var originalFilename: String? { get } And PHAssetResource has the following API: @available(iOS, introduced: 9, deprecated: 27, message: "Use filename instead") open var originalFilename: String { get } /// The filename associated with this asset resource (if any) @available(iOS 27, *) open var filename: String? { get } I'm confused why PHAssetExtendedMetadata (iOS 27+) has originalFilename while PHAssetResource originalFilename was deprecated and replaced with filename. I would have expected PHAssetExtendedMetadata's property be named filename to match. Are all 3 of these all the exact same name or can there be differences?

Here is a natural, professional English translation suitable for a bug report (such as filing via Apple's Feedback Assistant): Title / Summary Photos app defaults to creation time instead of EXIF date when region and time format are mismatched Bug Description Photos saved or received in the system Photos app (via downloads, AirDrop, etc.) use the saving timestamp as their capture date instead of preserving the photo's original metadata/EXIF timestamp. Steps to Reproduce Go to Settings > General > Language & Region. Set a Region whose default time format differs from your custom toggle (e.g., set Region to Japan, which defaults to a 24-hour clock, but manually switch the time format toggle to 12-Hour Time). Save or receive an image via AirDrop/download. Observe that the photo's original date metadata is ignored and replaced by the current timestamp. Root Cause Analysis The bug occurs when the device's custom time format (12/24-hour) mismatches the default time format of the selected Region, causing date metadata parsing to fail in the Photos app. Workaround Resetting the time format back to match the Region's default setting resolves the issue. Expected Result The system should correctly parse and preserve original image creation dates regardless of custom region or time format overrides. This issue should be resolved in a future software update. Affected OS Versions iOS 17+ iPadOS 17+ macOS 14 (Sonoma)+

Is there an expected date for Canon R5 Mark II raw 9 support?

It's unclear if this is a bug or a new feature but I have noticed that my photos starting coming out looking more stylised than expected and worked out that it was because photographic styles were being applied even tho I was taking photos through a third party app. Is there a way to disable this behaviour if it is intended? I've raised a feedback report #FB23632714 Photographic Styles [OFF] Photographic Styles [ON] My settings: