Hello Apple Developer Support, I’m developing a virtual camera using the CMIOExtensionDevice / CMIOExtensionStreamSource APIs on macOS. While the virtual camera appears in system settings and apps like Zoom and Google Meet, the video output exhibits the following issues: Jittering frames: The first frame sometimes appears correctly, but subsequent frames flicker or jitter. Solid color fill: Eventually, the camera feed fills entirely with a solid accent color (e.g., blue), rather than the intended video content. Console logs: Repeated messages appear in Console.app: Invalid display 0x00000000 Setup details: The virtual camera is created using CMIOExtensionDevice and CMIOExtensionStream. Video frames are rendered from NSImage/CGImage using CGContext and copied into CVPixelBuffers. Frame delivery is controlled by a DispatchSourceTimer at 60 FPS. macOS version: [Your macOS version here] Xcode version: [Your Xcode version here] Observations: The Invalid display 0x00000000 logs suggest that CGContext drawing or NSImage operations are failing in headless mode (i.e., there is no real display attached to the virtual camera). Using CIContext with .useSoftwareRenderer = true appears to mitigate some flicker, but not entirely. Questions / Requests: Is it expected that CoreMediaIO virtual cameras cannot reliably render CGImage / NSImage frames offscreen? Are there recommended APIs or approaches to render virtual camera frames fully headless to avoid display-dependent jitter? Is there any documentation or sample code from Apple showing stable video output from a virtual camera extension that does not rely on a physical display? Any guidance or examples would be greatly appreciated. This issue prevents the virtual camera from being used reliably in standard video apps. Thank you, Savvy

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 in this function, I am 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.

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 }

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)"

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'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.

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

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

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.

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.

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'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?

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?

This is an issue with the Insta360 Flow Pro 2. My iOS app uses DockKit to control the gimbal; in particular, my app disables tracking and sends angular velocity commands to control the gimbal's orientation. I only try to modify the yaw (rotation around the vertical axis); never the pitch or yaw. Note that I don't send the gimbal to a particular orientation directly; I modify the velocity. Everything works great for a long period of time: typically for a continuous run of 4-6 hours; in the most recent case, I managed about 36 hours of continous operation before the following problem occurred. I came back to check on the system, and because no visual activity had occurred in the camera's field of view for a while, the phone had commanded the gimbal to rotate back to a yaw angle of 0 degrees. So the phone in the gimbal should have been looking straight ahead (i.e. the 0 degree yaw position), but it was definitely looking off at an angle. I've seen this twice now. The first time, when it should have been looking straight ahead, it was in fact looking 60 degrees off center. This time (caught on video, see below), it was off by 22 degrees from center. Here's the weird part: the gimbal reports this way off center positioning as zero degrees (well close enough to zero, like 0.2 or something that's fine). But, mechanically, the gimbal still knows where zero degrees is: if we double click on the trigger of the Flow Pro 2, which is supposed to reset the gimbal to 0 degrees yaw and pitch, the gimbal responds correctly and reorients to a 0 degree position. However, the yaw values it reports are not zero, but as shown in my video, 22 degrees off axis or so. Power cycling the gimbal and restarting immediately fixes the problem. Also, I switched from my app to the Insta360 app, which caused the phone to flip from landscape to portrait, then when I returned to my app and switched back to landscape, the gimbal now started reporting correct yaw angles. Is there a possibility this is a bug in the DockKit framework? Has anyone seen this? I have a case open with Insta360, but although it's clearly a software issue, it's not clear if it's in Insta360's code or the DockKit layer. Any ideas for how I can get out of this mode? My concern is that the phone is in a tripod about 10' off the floor, and not very accessible. Also, if all goes well, we may have about 50 of these systems running, and having to fix them one by one after a few hours is not good. For a demonstration of this bug, see the following video: https://octoparry.com/offset.MOV Any help greatly appreciated.

I'm working on an application that uses the iPhone camera for scientific purposes - and, as a result would like to receive sensor data in as unprocessed format as possible. I'm using AVCapturePhotoOutput to take Bayer RAW stills and receiving data in kCVPixelFormatType_14Bayer_RGGB format. However, I'm puzzled as to the content of the bits. I simply demosaic the image by taking each 2x2 square: RG GB and use R, (G+G)/2, B to get 16-bit RGB values - and this indeed works. However, I am puzzled as to the values we are getting as they seem to be approximately in the range 2048 - 16383. The top value is understandable - the maximum that you can fit in 14-bits (as implied by the pixel format type). However we don't seem to be able to get lower than ~2048 no matter how black/dark we make the sensor. I'm aware that the sensor is probably not 14-bits (we're using the iPhone 16e camera) and that maybe this is to do with the way the sensor data is packaged. The Advances in iOS Photography video (https://developer.apple.com/videos/play/wwdc2016/501/) describes it as "10-bit sensor RAW packaged in 14 bits per pixel instead of eight." Is there any documentation describing what is going on here? It's vital for our use that we get as close to the raw camera sensor light readings as possible, so any pointers as to the mapping (e.g. decompanding?) being used would be extremely useful. Many thanks in advance for your help.

Hi guys, How to achieve the following feature on macOS when a USB device (Camera/Mic/Speaker) is connected: When a third-party video conferencing app is not in a meeting, ensure the app defaults to using the USB device (Camera/Mic/Speaker). When a third-party conferencing app is in a meeting, ensure the app automatically switches to the USB device (Camera/Mic/Speaker). I want to make use of IOKit extension to hidden or ignore build-in camera to realize the requirement. however the extension can't be loaded for Invalid permissions in MacOS 15.4.1, buildVersion:24E263. I also tried to run in in MacOS 14.4.1, which can be loaded but can't auto load when restart laptop as KDK version not match. Could you please give me some suggestion? Is it possible hidden build-in camera in MacOS M-series chip? Is there any other method to realize the feature. Thanks a lot.

Hi guys, Can I use CMIO to achieve the following feature on macOS when a USB device (Camera/Mic/Speaker) is connected: When a third-party video conferencing app is not in a meeting, ensure the app defaults to using the USB device (Camera/Mic/Speaker). When a third-party conferencing app is in a meeting, ensure the app automatically switches to the USB device (Camera/Mic/Speaker).

Does the library exists in xCode 16.4? "import WorldCaptureKit" gives error "No such module 'WorldCaptureKit'". And I do not find any information about the library in the apple documentation. But AI keeps suggesting me to use the library

Can i use iokit usb lib to disable build-in camera?

iOS 26 added smoothness to CIRoundedRectangleGenerator, for use with CIFilter.roundedRectangleGenerator. What should the smoothness value be to achieve the same corner curve as CALayerCornerCurve.continuous? Does it need to be calculated based on the extent size, if so, how?