I am developing an iOS camera app that can record video directly to external storage connected to an iPhone. To detect whether an external USB storage device is connected and to obtain its URL, I am considering using AVExternalStorageDeviceDiscoverySession. However, when checking support using AVExternalStorageDeviceDiscoverySession.isSupported, I observe that it returns true only on Pro model iPhones, and false on non-Pro models in my environment. I have reviewed Apple’s official documentation, but I could not find any clear description of the supported devices or requirements (for example, whether this API is limited to Pro models or requires specific hardware capabilities). I would appreciate any information regarding the following points: ①The actual requirements for AVExternalStorageDeviceDiscoverySession to be supported Device limitations (Pro vs non-Pro models) Hardware requirements (USB controller, external recording capability, etc.) iOS version dependencies ②Whether support for non-Pro models is planned in the future Tested environments iPhone 16 Pro (iOS 18.7.1) → isSupported == true iPhone 16e (iOS 26.2) → isSupported == false iPhone 17 (iOS 26.2) → isSupported == false iPhone Air (iOS 26.2) → isSupported == false If anyone has observed similar behavior or has official information from Apple regarding this API, I would greatly appreciate your insights.

I am developing an iOS camera app that can record video directly to external storage connected to an iPhone. To detect whether an external USB storage device is connected and to obtain its URL, I am considering using AVExternalStorageDeviceDiscoverySession. However, when checking support using AVExternalStorageDeviceDiscoverySession.isSupported, I observe that it returns true only on Pro model iPhones, and false on non-Pro models in my environment. I have reviewed Apple’s official documentation, but I could not find any clear description of the supported devices or requirements (for example, whether this API is limited to Pro models or requires specific hardware capabilities). I would appreciate any information regarding the following points: ●The actual requirements for AVExternalStorageDeviceDiscoverySession to be supported Device limitations (Pro vs non-Pro models) Hardware requirements (USB controller, external recording capability, etc.) iOS version dependencies ●Whether support for non-Pro models is planned in the future Tested environments iPhone 16 Pro (iOS 18.7.1) → isSupported == true iPhone 16e (iOS 26.2) → isSupported == false iPhone 17 (iOS 26.2) → isSupported == false iPhone Air (iOS 26.2) → isSupported == false If anyone has observed similar behavior or has official information from Apple regarding this API, I would greatly appreciate your insights.

Hello, We are trying to use the new Background Upload Extension to improve uploads of assets (Photos, Live Photos, Videos) in the background in our application. 1-The assets have finished uploading, but I'm unable to retrieve successful records using PHAssetResourceUploadJob.fetchJobs(action: .acknowledge, options: nil). When will the successful records be returned? 2-How to retrieve the system's pending tasks? We want to cancel tasks handed over to the system when returning to the main app to avoid duplicate resource uploads. 3-When we set UploadJobExtensionEnabled = true, will tasks handed over to the system still execute after returning to the main app? Do we need to set UploadJobExtensionEnabled = false upon returning to the main app? If we set UploadJobExtensionEnabled = false, will previously submitted upload tasks be cleared?

Hello, We are trying to use the new Background Upload Extension to improve uploads of assets (Photos, Live Photos, Videos) in the background in our application. 1-The assets have finished uploading, but I'm unable to retrieve successful records using PHAssetResourceUploadJob.fetchJobs(action: .acknowledge, options: nil). When will the successful records be returned? 2-How to retrieve the system's pending tasks ? We want to cancel tasks handed over to the system when returning to the main app to avoid duplicate resource uploads. 3-When we set UploadJobExtensionEnabled = true, will tasks handed over to the system still execute after returning to the main app? Do we need to set UploadJobExtensionEnabled = false upon returning to the main app? If we set UploadJobExtensionEnabled = false, will previously submitted upload tasks be cleared?

Hi Apple Developer Forums, I’m developing an iOS camera app that processes RAW captures using Core Image. I’m seeing a large “first use” performance penalty specifically when creating the CIImage from CIRAWFilter.outputImage. What’s slow (important detail) I’m measuring the time for: let rawFilter = CIRAWFilter(imageData: rawData, identifierHint: hint) let ciImage = rawFilter.outputImage This is not CIContext.render(...) / createCGImage(...). It’s just the time to access outputImage (i.e., building the Core Image graph / RAW pipeline setup). Observed behavior First time accessing CIRAWFilter.outputImage: ~3 seconds Second time (same app session, similar RAW): ~3 milliseconds So something heavy is happening only on first use (decoder initialization, pipeline setup, shader/library compilation, caching, etc.). Using Metal System Trace, I also noticed that during the slow first call there are many “Create MTLLibrary” events, while the second call doesn’t show this pattern. Warm-up attempts using bundled DNG I tried to “warm up” early (e.g., on camera screen entry) by loading a bundled DNG and then accessing CIRAWFilter.outputImage by taking a photo: Warm-up with a ~247 KB DNG → first real RAW outputImage cost drops to ~1.42s Warm-up with a ~25 MB DNG → first real RAW outputImage cost drops to ~843ms This helps, but it’s still far from the steady-state ~3ms. Warm-up by capturing a real RAW (works, but concerns) The only method that fully eliminates the delay is to trigger a real RAW capture programmatically before the user’s first photo, then use that captured rawData to warm up the CIRAWFilter.outputImage path. This brings the first user-facing capture close to the steady-state timing. However: In some regions, the camera shutter sound cannot be suppressed, so “hidden warm-up capture” is unacceptable UX. I’m also unsure whether triggering a real capture without an explicit user action could raise compliance/privacy concerns, even if the image is immediately discarded and never saved/uploaded. Questions Is the large first-time cost of CIRAWFilter.outputImage expected (RAW pipeline initialization / shader compilation)? Is there an Apple-recommended way to pre-initialize the Core Image RAW pipeline / Metal resources so the first outputImage is fast, without taking a real photo? Are there any best practices (e.g. CIContext creation timing, prepareRender(...), specific options) that reliably reduce this first-use overhead for CIRAWFilter? Attachments Figure 1: First RAW capture with no warm-up (~3s outputImage time) Figure 2: First RAW capture after warm-up with bundled DNG (improved but still hundreds of ms) Thanks for any guidance or experience sharing!

We are planning to develop an app that connects to a UVC camera to capture and display video via AVFoundation. Could you please advise on which iPhone models support UVC cameras?

I am new to Swift and iOS development, and I have a question about video capture performance. Is it possible to capture video at a resolution of 4032×3024 while simultaneously running a vision/ML model on the video stream (e.g., using Vision or CoreML)? I want to know: whether iOS devices support capturing video at that resolution, whether the frame rate drops significantly at that scale, and whether it is practical to run a Vision/ML model in real-time while recording at such a high resolution. If anyone has experience with high-resolution AVCaptureSession setups or combining them with real-time ML processing, I would really appreciate guidance or sample code.

PHPhotoLibrary.authorizationStatus(for: .readWrite) == .authorized Iinfo.plist Privacy - Photo Library Usage Description set I check authorization before attempting to get the photoPickerItem.itemIdentifier, but every time the return value from itemIdentifier is nil. Seems I missing some permissions, but unsure why the system is still keeping _shouldExposeItemIdentifier set to false.

Hey, There seems to be an inconsistency when capturing a photo using QualityPrioritization.Quality on the iPhone 17 Pro Main wide Lens. If you zoom above "2x" the output image always has "-2.0ev" bias in the meta data and looks underexposued. This does not happen at zoom levels above 2, or if you set the QualityPrioritization to .Balanced. See below: with .Quality with .Balanced This does not happen on the other lenses. I'm using a simple set up and it is consistent across JPEG and ProRAW capture. I have a demo project if that is useful. Thanks, Alex

I'm using this library: https://github.com/Yummypets/YPImagePicker to capture photos. I've modified it slightly, and I'm using an older version. When testing on my iPhone 16e, ios 26, whenever I take a photo, I get the following two error messages: <<<< FigXPCUtilities >>>> signalled err=-17281 at <>:302 <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:569) - (err=-17281) These error messages appear, but as far as I can tell, the photo comes through OK, and I can save the data no problem. I've even removed all my handling code to see if it was something I was doing. I don't really want to ship with these errors showing, but I also have no idea what can be causing this error to appear. chatgpt was not helpful diagnosing this. Does anyone know what can cause this error Is there a way I can see the source code to figure out if there's something I'm doing wrong here? It really seems like this is an internal apple error, or else I would have expected more details on the error relating to the code I've written. Any clues would be appreciated!

Device: iPhone 17 Pro iOS Version: iOS 26.1 Camera: Ultra-wide (0.5x) using AVCaptureSession Our camera app freezes on iPhone 17 when switching frame rates (30fps ↔ 60fps). This works fine on iPhone 16 Pro and earlier. What We've Observed: Freeze happens on frame rate change - particularly when stabilization was enabled Thread.sleep is used - to allow camera hardware to settle before re-enabling stabilization Works on older iPhones - only iPhone 17 exhibits this behavior Console shows these errors before freeze: 17281 <<<< FigXPCUtilities >>>> signalled err=18446744073709534335 <<<< FigCaptureSourceRemote >>>> err=-17281 Is Thread.sleep on the main thread causing the freeze? Should all camera configuration be on a background queue? Is there something specific about iPhone 17 ultra-wide camera that requires different handling? Should we use session.beginConfiguration() / session.commitConfiguration() instead of direct device configuration? Is calling setFrameRate from a property's didSet (which runs synchronously) problematic? Are the FigCaptureSourceRemote errors (-17281) indicative of the problem, and what do they mean?

I'm trying to benchmark a Core Image filter chains memory footprint and notice a weird quirk in instruments. On a real device, even with a simple Core Image chain, the memory balloons each time I ran the filter. See attached screen shots. Running on iPhone 17 Pro: Running on simulator (M2 Macbook Pro) As you can see there's a huge build up of 4MB "VM: IOSurface" memory on the real device, but the simulator seems to clean it up correctly. Here's my basic code: func processImage() { guard let inputImage = ContentViewModel.loadImageFromBundle(name: "kitty.HEIC") else { print("Failed to load sample_image from bundle") return } var outputImage = inputImage outputImage = outputImage.applyingFilter("CIBloom", parameters: [ kCIInputRadiusKey: 20, kCIInputIntensityKey: 0.8 ]) DispatchQueue.global(qos: .userInitiated).async { let data = self.context.jpegRepresentation(of: outputImage, colorSpace: CGColorSpace(name: CGColorSpace.sRGB)!) if let data = data, let uiImage = UIImage(data: data) { DispatchQueue.main.async { self.displayImage = Image(uiImage: uiImage) } } } } Why is this happening? Seems like a bug to me or I need to release an object. At the very least makes it challenging to measure memory usage. Any help is greatly appreciated. Alex

Hi, I’m trying to implement the new PhotoKit PHBackgroundResourceUploadExtension. I created the extension, enabled full photo library access in the host app, and registered the extension point using the string: com.apple.photos.background-upload. However, when I attempted to enable the extension with: try library.setUploadJobExtensionEnabled(true) I received the following error: Error Domain=PHPhotosErrorDomain Code=-1 "(null)" This happens when running the app on Xcode 26.1 and 26.2 Beta, using the iPhone 17 Pro Max simulator (iOS 26.1 and 26.2). My question is: Is this extension supported on the simulator? I’m asking because at the moment it’s difficult for me to test this on a physical device. Also, What's the meaning of the error? Thanks.

Recently Apple gave us the possibility to upload asset resources in the background. We implemented our background upload extension but when our CI tried to upload the app on TestFlight we got an error that the extension point identifier - in our case com.apple.photos.backgound-upload - is not an official one. Any idea when it will become official and we will be able to release a working background uploading?

Apple Watch app closes when changing photo permissions in the iPhone app. App A is installed simultaneously on both the paired iPhone and Apple Watch. I'm running App A on both my iPhone and Apple Watch. When I change the photo permissions on App A installed on my iPhone, App A running on my Apple Watch automatically closes. At first, I assumed App A on my iPhone was abnormally closing, causing App A on my Apple Watch to also close. However, I've determined that changing the photo permissions is the cause of the app closing. I don't think this behavior existed before WatchOS/iOS 26. Is this behavior a natural addition to WatchOS/iOS 26? If I go to the home screen while running app A on my iPhone and change its photo permissions in the Settings app, app A running on my Apple Watch automatically closes.

The introduction of PHBackgroundResourceUploadExtension is a welcome addition in iOS 26.1. I wonder however, how to attach a debugger and actually get the system to call the process() method of the extension. I tried to run the extension both inside photos app (and also the main app for testing), but when I take a photo or add photos to the library (saving), the process() method does never get called. Any hints would be appreciated to debug the PHBackgroundResourceUploadExtension during development.

1.May I ask if the Background Upload can run normally in the Release version of ios 26.1? I used the Release version of ios 26.1 for debugging and found that the background upload couldn't be triggered for a long time. I debugged in ios 26.2 and found that background upload could be triggered normally, but kept triggering an Error: "Error returned from daemon: error Domain=com.apple.accounts Code=7 "(null)"

we are working on HDR images and found this problem, asset.mediaSubtypes.contains(.photoHDR) always return false func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) { guard !results.isEmpty else {return} let fetchResult = PHAsset.fetchAssets(withLocalIdentifiers: results.map({$0.assetIdentifier!}), options: nil) var selectedAssets:[PHAsset] = [] fetchResult.enumerateObjects { asset, _, _ in selectedAssets.append(asset) } for i in selectedAssets.enumerated() { let asset:PHAsset = i.element print("\(i.offset): ") print(PHAssetMediaSubtype.photoHDR.rawValue) print(asset.mediaSubtypes) print("photoHDR \(PHAssetMediaSubtype.photoHDR.rawValue): \(asset.mediaSubtypes.contains(.photoHDR))") print("photoLive \(PHAssetMediaSubtype.photoLive.rawValue): \(asset.mediaSubtypes.contains(.photoLive))") print("photoPanorama \(PHAssetMediaSubtype.photoPanorama.rawValue): \(asset.mediaSubtypes.contains(.photoPanorama))") print("photoScreenshot \(PHAssetMediaSubtype.photoScreenshot.rawValue): \(asset.mediaSubtypes.contains(.photoScreenshot))") print("videoHighFrameRate \(PHAssetMediaSubtype.videoHighFrameRate.rawValue): \(asset.mediaSubtypes.contains(.videoHighFrameRate))") print("videoScreenRecording \(PHAssetMediaSubtype.videoScreenRecording.rawValue): \(asset.mediaSubtypes.contains(.videoScreenRecording))") } }

On iOS 26.1, this throws on the 2020 iPad Pro (4th gen) but works fine on an M4 iPad Pro or iPhone 15 Pro: guard let device = AVCaptureDevice.default(.builtInLiDARDepthCamera, for: .video, position: .back) else { throw ConfigurationError.lidarDeviceUnavailable } It's just the standard code from Apple's own sample code so obviously used to work: https://developer.apple.com/documentation/AVFoundation/capturing-depth-using-the-lidar-camera Does it fail because Apple have silently dumped support for the older LiDAR sensor used prior to the M4 iPad Pro, or is there another reason? What about the 5th and 6th gen iPad Pro, does it still work on those?

If the app is launched from LockedCameraCapture and if the settings button is tapped, I need to launch the main app. CameraViewController: func settingsButtonTapped() { #if isLockedCameraCaptureExtension //App is launched from Lock Screen //Launch main app here... #else //App is launched from Home Screen self.showSettings(animated: true) #endif } In this document: https://developer.apple.com/documentation/lockedcameracapture/creating-a-camera-experience-for-the-lock-screen Apple asks you to use: func launchApp(with session: LockedCameraCaptureSession, info: String) { Task { do { let activity = NSUserActivityTypeLockedCameraCapture activity.userInfo = [UserInfoKey: info] try await session.openApplication(for: activity) } catch { StatusManager.displayError("Unable to open app - \(error.localizedDescription)") } } } However, the documentation states that this should be placed within the extension code - LockedCameraCapture. If I do that, how can I call that all the way down from the main app's CameraViewController?