I'm developing a native macOS menu-bar utility that aims to toggle USB power to an iPhone connected directly to a MacBook Pro. Hardware: MacBook Pro with M2 Pro iPhone 13 connected via USB-C to Lightning No external hubs or adapters Goal: I want to temporarily stop the iPhone from charging without physically disconnecting the cable, then restore charging programmatically. Losing the USB data connection while power is disabled is completely acceptable. What I've investigated: uhubctl doesn't expose the built-in USB-C ports as controllable in my setup. IOKit and USBDriverKit provide USB device management, but I haven't found a supported method to disable physical VBUS. I found IOUSBHostCIMessageTypePortPowerOff, but it appears to relate to host-controller interfaces rather than controlling Apple's existing USB-C hardware. My questions: Is there any supported API or system-level mechanism for disabling VBUS on a MacBook's built-in USB-C port? Can the USB-C Power Delivery controller be instructed to stop supplying power without physically disconnecting the device? Alternatively, is there a supported mechanism for requesting that a connected iPhone temporarily stop drawing charging current? I'm open to lower-level macOS development if necessary, but I'd like to understand whether this is technically possible before pursuing it. Any insight from Apple engineers or developers familiar with Apple Silicon USB controllers would be greatly appreciated.

I'm looking into direct communication between a Mac and a Linux machine connected over Thunderbolt. Thunderbolt networking works fine, but I'd like to explore whether it's possible to transfer data using native Thunderbolt DMA, without going through the TCP/IP stack. I've looked through the IOKit and DriverKit documentation, but most of what I've found relates to drivers for PCIe devices connected over Thunderbolt rather than communication between two hosts. A couple of questions: Is there a supported API for discovering Thunderbolt XDomain services and establishing native DMA-backed send/receive paths between hosts? Can this be done from userspace or DriverKit, or would it require a kernel extension? Ideally, I'd also like to keep the existing Thunderbolt networking interface working alongside it. Any pointers to relevant APIs or documentation would be appreciated. Thanks!

Hello, I’m developing a native macOS application intended for Mac App Store distribution, with App Sandbox enabled. The intended feature is to let users connect their personal iPhone or iPad via USB, read the existing Home Screen layout, rearrange app icons and folders on the Mac, and apply the user-approved layout back to the device. The target devices are ordinary, non-supervised consumer devices, without MDM enrollment. Our current prototype detects the connected iPhone through public IOKit registry APIs. It does not access the Home Screen layout or modify the device. I have reviewed USB access entitlements and the device-management HomeScreenLayout payload, but have not identified a public API for this consumer-device workflow. Is there a public, supported API or documented integration mechanism for reading and updating these Home Screen layouts from a sandboxed macOS app? If supported, which framework and entitlements should we use? We would also need to understand any limitations around preserving folders, Dock contents, widgets, and empty icon positions. If this capability is not available through public APIs, could you clarify that limitation and the appropriate channel for submitting an enhancement request? This is a question about technical API availability, rather than a request for advance App Review approval. Thank you.

Dear Apple Developer Support, We develop a Mac Catalyst app that has the com.apple.vm.device-access entitlement. We are now able to redirect USB devices to a remote virtual machine using the SPICE remote desktop protocol. We have run into a case where the only working solution we have found depends on an API that the SDK marks as unavailable for Mac Catalyst. We would like to understand the supported approach before submitting a build for review. The app uses libusb's Darwin backend to capture a USB device before redirecting it. The capture sequence is the standard one: IOServiceAuthorize(service, kIOServiceInteractionAllowed) USBDeviceReEnumerate(device, kUSBReEnumerateCaptureDeviceMask) USBDeviceOpenSeize, then USBInterfaceOpen on the captured device A) Behaviour without step 1 IOKitLib.h annotates IOServiceAuthorize with __API_UNAVAILABLE(ios, macCatalyst), so our first implementation skipped it on Catalyst and went straight to the capture re-enumeration. In that configuration: The entitlement is present and readable via SecTaskCopyValueForEntitlement. USBDeviceReEnumerate with kUSBReEnumerateCaptureDeviceMask returns kIOReturnSuccess. The device does re-enumerate — it disappears and reappears on the host, and its volumes are unmounted. The kernel drivers then re-attach, and the following USBInterfaceOpen fails with kIOReturnExclusiveAccess ("another process has device opened for exclusive access"). The capture reports success but does not actually take the device away from the system's drivers. This is reproducible with a USB mass-storage device (a flash drive with a mounted volume). B) Behaviour with step 1 If IOServiceAuthorize is called before the re-enumeration, capture works correctly and USB redirection functions as expected. To call it from a Catalyst target we had to work around the availability annotation by binding the symbol directly: extern kern_return_t my_service_authorize(io_service_t service, uint32_t options) asm("_IOServiceAuthorize"); This compiles, links and runs. We note that IOKit.tbd in the macOS SDK exports _IOServiceAuthorize for the arm64-maccatalyst and x86_64-maccatalyst targets, which is why it links. Our questions are as follows: With com.apple.vm.device-access granted, what is the supported way to authorize USB device capture from a Mac Catalyst app? If IOServiceAuthorize is the intended mechanism, is calling it from Catalyst as shown above acceptable for App Store review, given the __API_UNAVAILABLE(macCatalyst) annotation on its declaration? If it is not acceptable, is there a Catalyst-available equivalent? Or is the entitlement expected to make USBDeviceReEnumerate(kUSBReEnumerateCaptureDeviceMask) sufficient on its own? If the latter is the intent, the behaviour described above suggests it is not currently sufficient, and we would be glad to file a bug report with a reproducible case. We would rather not ship an API usage that could be read as circumventing a platform availability annotation, which is why we are asking before submitting. Thank you, Morpheusly Inc. development team

Hello, does anyone know how to permanently disable the built‑in display in macOS 15 on iMac M1 programmatically or via the terminal? I’m facing a problem — the display cable is broken. As a result, not only does it work poorly, but there’s also severe overheating in the upper right part of the iMac. The warranty has expired, and I don’t have the funds to replace the display right now. So I’m looking for ways to disable the built‑in screen and work only with an external display. At the moment, I’ve found a way to disable the display after logging in, but before logging in, the screen gets hot, and in this mode I won’t be able to upgrade to the new operating system. The process is lengthy, and the screen will become significantly hot. Ideally, the built‑in display should be disabled during reboot and when upgrading to a new version of macOS, and an external display should be used as the main display.

We are investigating a Mac App Store version of an app that provides tap-to-click and two-finger dragging for Magic Mouse. We need contact identity, finger positions, touch-down/up, and simultaneous contact count while the pointer is over other apps. We want a supported public API and normal App Sandbox entitlements. We are not asking how to use a private framework or bypass the sandbox. Environment tested: macOS 27.0.1 (26A434), Apple Silicon arm64, Bluetooth Magic Mouse vendor 0x004c / product 0x0269. Both IOHIDManager/IOHIDDevice and CoreHID are tested in a standalone sandboxed diagnostic app, signed with a persistent local certificate. Sandbox is confirmed via SecTask, Input Monitoring granted via System Settings and confirmed by IOHIDCheckAccess. Entitlements: app-sandbox, device.usb, device.bluetooth. No temporary exceptions, no seizeDevice, no SetReport or device reconfiguration. The normal app was still running during capture; we can repeat with it stopped if necessary. We discover four mouse interfaces, primary usage pairs FF00/03, FF00/12, FF00/0B, and 01/02. All open successfully after Input Monitoring is granted. The latter descriptor includes a 0D/05 Touch Pad collection but only vendor-defined payload for that collection. Standard individual contact fields are not declared. Input report IDs 0x3f and 0x44 are declared in addition to mouse report 0x12. Two 60-second captures, one per API, include user-performed phases for hands off, one finger, two fingers, moving each finger independently, scrolling, and physical movement/click. IOHID received 1310 input reports; CoreHID received 2349. Every report was ID 0x12, 8 bytes. Element updates were exclusively Generic Desktop X/Y, without individual contact identity or finger coordinates. Neither 0x3f nor 0x44 was delivered. The diagnostic client only reads mouse interfaces and does not read keyboard input. Questions: Is there a supported public API to observe global individual Magic Mouse contacts in an App Sandbox app, including when another app is active? Is individual-contact data expected to be available through IOHIDDevice input reports or CoreHID for this device? If so, what documented setup and entitlements are required? Are the declared vendor-defined reports 0x3f/0x44 intended for third-party clients, and is their payload documented for this purpose? If there is no supported public route, should this functionality remain outside the Mac App Store, or is there a supported capability path we should investigate? The diagnostic source is independent of the production app. Please advise whether further captures with all other input utilities stopped would help distinguish a driver/client interaction from an unsupported use case. No logs or source attachments are included in this public post.

Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.

Hi, I would like to update that we have a kext that has IOStorageFamily in OSBundleLibraries. I would like to know whether we can create DriverKit that support this family and embed in SystemExtension for deployment? and we have another kext that has combination of IOStorageFamily and IOUSBFamily in OSBundleLibraries. Please let me know whether such type of Kext can be converted into DriverKit. I am new to DriverKit development. Please let us know if there is any sample that has these bundles in DriverKit so that I can check. Please let us know if such are supported with DriverKit then what are the capabilities that we need to add in entitlement request so that it can get approved. Thanks & Regards, Mohmad Vasim

Environment: macOS 26.6.2 (25G83), Apple silicon Xcode 26.6 (17F113) DriverKit SDK 25.5 I am implementing a DriverKit IOService with an IOUserClient. This is a lifecycle and object-ownership question independent of the device protocol. The intended design admits at most one user client during a provider lifetime. Lifecycle methods run on the provider’s default queue, while IOUserClient ExternalMethod requests run on a separate serial IODispatchQueue. At most one device request may be in flight. The shutdown invariant we need is: Stop accepting new requests. Allow every accepted request to complete exactly once, or cancel it. Observe completion of the operation queue’s cancellation handler. Call the inherited Stop implementation last. Perform no provider access afterward. The relevant public documentation is: IOService::Stop: https://developer.apple.com/documentation/driverkit/ioservice/stop IODispatchQueue::Cancel: https://developer.apple.com/documentation/driverkit/iodispatchqueue/cancel IOService::SetDispatchQueue: https://developer.apple.com/documentation/driverkit/ioservice/setdispatchqueue For the normal path, the proposed sequence is conceptually: Stop(provider): close request admission operationQueue->Cancel(cancellationHandler) wait for the cancellation handler from the separate queue super::Stop(provider) I need clarification of the complete supported public API contract: If IODispatchQueue::Cancel returns a non-success result, is its cancellation handler still guaranteed to execute? If it is not, what supported action lets Stop keep the provider and user client valid until previously accepted work is no longer capable of accessing them? Is it supported for the provider and its one user client to share the provider-owned serial operation queue? If the IOUserClient stops independently, must it own and cancel a separate queue, or is there a supported per-client drain mechanism that does not cancel provider-owned work? Is the driver’s public IOService::Stop override guaranteed to run on every termination path where accepted user-client work must be drained, including when the provider is already inactive or the DriverKit server has slept? If not, which public lifecycle callback supplies that drain point? Is blocking the provider’s default queue inside Stop while awaiting the cancellation handler from a separate operation queue the supported interpretation of “wait for your cancellation handlers”? If not, what public continuation mechanism should be used before calling inherited Stop? We also observed one power-management panic after sleep/wake: HiMDScsiDriver::setPowerState(..., 0 -> 4) timed out after 20342 ms The DEXT does not currently override SetPowerState. This panic motivates the lifecycle review, but I am not treating it as proof that the Stop/drain design caused the timeout. I am looking specifically for a supported public DriverKit sequence. I do not want to rely on private framework entry points or infer object-lifetime guarantees from a successful build or experiment.

Hello @all I'm develop a DriverKit driver extension and without entitlement checks by OS everything runs fine. But if the entitlements check is enabled in the NVRAM then I get an error due connecting my IOUserClient instance. Which entitlements are really and exactly required for my driver? My driver contains: one IOUserClient instance and multiple IOUserSerial instances The bundle identifier of the driver ist: org.eof.tools.VSPDriver The bundle identifier of the client app org.eof.tools.VSPInstall My entire source code is available on GitHub if any one want to dive deep in :) kernel[0:5107] () [VSPDriver]: NewUserClient called. kernel[0:5107] () [VSPDriver]: CreateUserClient: create VSP user client from Info.plist. kernel[0:5107] () [VSPUserClient]: init called. kernel[0:5107] () [VSPUserClient]: init finished. kernel[0:5107] () [VSPDriver]: CreateUserClient: check VSPUserClient type. kernel[0:5107] () [VSPDriver]: CreateUserClient: success. kernel[0:5107] () [VSPDriver]: NewUserClient finished. kernel[0:5107] () [VSPUserClient]: Start: called. kernel[0:5107] () [VSPUserClient]: User client successfully started. kernel[0:389f] DK: VSPUserClient-0x100001127:UC failed userclient-access check, needed bundle ID org.eof.tools.VSPDriver kernel[0:389f] DK: VSPUserClient-0x100001127:UC entitlements check failed kernel[0:5107] () [VSPUserClient]: Stop called. kernel[0:5107] () [VSPUserClient]: User client successfully removed. kernel[0:5107] () [VSPUserClient]: free called. Here my drivers entitlement file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.family.serial</key> <true/> </dict> </plist> Here my drivers Info.plist file <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>NSHumanReadableCopyright</key> <string>Copyright © 2025 by EoF Software Labs</string> <key>OSBundleUsageDescription</key> <string>Provide virtual serial port</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-any-userclient-access</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.system-extension.redistributable</key> <true/> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOSerialFamily</key> <string>1.0</string> </dict> <key>IOKitPersonalities</key> <dict> <key>VSPDriver</key> <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleIdentifierKernel</key> <string>com.apple.kpi.iokit</string> <key>IOMatchCategory</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOProviderClass</key> <string>IOUserResources</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOProbeScore</key> <integer>0</integer> <key>IOClass</key> <string>IOUserService</string> <key>IOUserClass</key> <string>VSPDriver</string> <key>IOUserServerName</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>VSPUserClient</string> </dict> <key>SerialPortProperties</key> <dict> <key>CFBundleIdentifierKernel</key> <string>com.apple.driver.driverkit.serial</string> <key>IOProviderClass</key> <string>IOSerialStreamSync</string> <key>IOClass</key> <string>IOUserSerial</string> <key>IOUserClass</key> <string>VSPSerialPort</string> <key>HiddenPort</key> <false/> <key>IOTTYBaseName</key> <string>vsp</string> <key>IOTTYSuffix</key> <string>0</string> </dict> </dict> </dict> </dict> </plist> Here the entitlements of the client app <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.shared-with-you</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>$(TeamIdentifierPrefix).org.eof.apps</string> </array> </dict> </plist> Here the Info.plist of the client app: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>LSMinimumSystemVersion</key> <string>$(MACOSX_DEPLOYMENT_TARGET)</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.install</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.system-extension.uninstall</key> <true/> <key>com.apple.developer.driverkit.userclient-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.private.driverkit.driver-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.security.temporary-exception.iokit-user-client-class</key> <array> <string>IOUserUserClient</string> </array> </dict> </plist>

I found some nice code that implements a NUT client, and now I want to take the next step -- I would like to get it to show up as a UPS for macOS. But I've never done anything with IOKit... and there don't seem to be a lot of examples of, maybe, IOPowerSources?

My application does the following cycle: Collect devices from IOHIDManagerRef using the IOHIDManagerRegisterDeviceMatchingCallback IOHIDDeviceOpen for the received IOHIDDeviceRef IOHIDDeviceRegisterInputReportCallback for the received IOHIDDeviceRef IOHIDDeviceClose for the received IOHIDDeviceRef IOHIDDeviceOpen for the received IOHIDDeviceRef IOHIDDeviceRegisterInputReportCallback for the received IOHIDDeviceRef I delete the "context" that I pass to the IOHIDDeviceRegisterInputReportCallback after the device closing. In this situation I observe that the registered call back is called on the delete callback. Does anyone have clue why the call back remains registered even after the device closing? I also tried to "unrgister" the callback manually using this trick: IOHIDDeviceRegisterInputReportCallback(dev, orig_buff_ptr, orig_buff_size, nullptr, orig_ctx); This doesn't help as well. I checked https://github.com/aosm/IOKitUser/blob/master/hid.subproj/IOHIDDevice.c already and it seems the IOHIDDeviceClose call should be enough to rid of the staling call back records. Thank you in advance!

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

Hi there, I am working on a little application which processes cursor and graphics tablet data and adds some extra control to the output. So far it makes use of... if let eventTap = CGEvent.tapCreate(tap: .cgSessionEventTap, //.cghidEventTap place: .headInsertEventTap, options: .defaultTap, eventsOfInterest: eventMask, callback: handleTapEvent, userInfo: userInfo) ... to modify existing events. The issue that in some cases arises (it's a globally working app) - that some other applications pull and process pointer-data aside the event stream and therefor create conflicting values. Would creating and posting events to a 'virtual pointing device' on a lower system level (kext) help? Let's discuss. BR, E

The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x<locationID><vendorID><productID>, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }

We have developed an IOPCIFamily based custom KEXT to communicate with Thunderbolt interface storage device. This KEXT is working fine with Apple machines with Intel CPUs in all types of machines (iMac, iMac Pro and MacBooks). We tested this KEXT with Apple Silicon M1 machine where we are observing crash for the very first command we send to the Thunderbolt device. We observed that there is difference in number of bits in Physical Address we use for preparing command PRPs. In Intel machines we get 28-Bit Physical Address whereas in M1 we are getting 36-Bit address used for PRPs. We use inTaskWithPhysicalMask api to allocate memory buffer we use for preparing command PRPs. Below are the options we have used for this: options: kIOMemoryPhysicallyContiguous | kIODirectionInOut capacity: 16kb physicalMask: 0xFFFFF000UL (We want 4kb aligned memory) According to below documentation, we have to use inTaskWithPhysicalMask api to get memory below 4gb. https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/KernelExtensionsandDrivers/KernelExtensionsandDrivers.html#//apple_ref/doc/uid/TP40001064-CH227-SW1 Some devices can only handle physical addresses that fit into 32 bits. To the extent that it is possible to use 64-bit addresses you should do so, but for these devices, you can either use IODMACommand or the initWithPhysicalMask method of IOBufferMemoryDescriptor to allocate a bounce buffer within the bottom 4 GB of physical memory. So just want to know what's the difference between Intel and ARM64 architecture with respect to physical memory access. Is there any difference between byte order for physical memory address..?? Crash log is given below: panic(cpu 0 caller 0xfffffe0016e08cd8): "apciec[0:pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x00020000 linkcdmsts=0x00000800 (ltssm 0x11=L0)\n" Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 20C69 Kernel version: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASEARM64T8101 Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34 Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536 iBoot version: iBoot-6723.61.3 secure boot?: YES Paniclog version: 13 KernelCache slide: 0x000000000dbfc000 KernelCache base: 0xfffffe0014c00000 Kernel slide: 0x000000000e73c000 Kernel text base: 0xfffffe0015740000 Kernel text exec base: 0xfffffe0015808000 machabsolutetime: 0x12643a9c5 Epoch Time: sec usec Boot : 0x5fe06736 0x0009afbc Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x5fe067fd 0x0006569d CORE 0 recently retired instr at 0xfffffe0015971798 CORE 1 recently retired instr at 0xfffffe0015972c5c CORE 2 recently retired instr at 0xfffffe0015972c5c CORE 3 recently retired instr at 0xfffffe0015972c5c CORE 4 recently retired instr at 0xfffffe0015972c60 CORE 5 recently retired instr at 0xfffffe0015972c60 CORE 6 recently retired instr at 0xfffffe0015972c60 CORE 7 recently retired instr at 0xfffffe0015972c60 Panicked task 0xfffffe166ce9e550: 75145 pages, 462 threads: pid 0: kernel_task Panicked thread: 0xfffffe166d053918, backtrace: 0xfffffe306cb4b6d0, tid: 141 lr: 0xfffffe0015855f8c fp: 0xfffffe306cb4b740 lr: 0xfffffe0015855d58 fp: 0xfffffe306cb4b7b0 lr: 0xfffffe0015977f5c fp: 0xfffffe306cb4b7d0 lr: 0xfffffe0015969914 fp: 0xfffffe306cb4b880 lr: 0xfffffe001580f7e8 fp: 0xfffffe306cb4b890 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc20 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc90 lr: 0xfffffe0015ff03f8 fp: 0xfffffe306cb4bcb0 lr: 0xfffffe0016e08cd8 fp: 0xfffffe306cb4bd60 lr: 0xfffffe00166bc778 fp: 0xfffffe306cb4be30 lr: 0xfffffe0015f2226c fp: 0xfffffe306cb4be80 lr: 0xfffffe0015f1e2f4 fp: 0xfffffe306cb4bec0 lr: 0xfffffe0015f1f050 fp: 0xfffffe306cb4bf00 lr: 0xfffffe0015818c14 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleEmbeddedPCIE(1.0)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.IODARTFamily(1)[88B19766-4B19-3106-8ACE-EC29201F00A3]@0xfffffe0017890000->0xfffffe00178a3fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff com.apple.driver.AppleT8103PCIeC(1.0)[35AEB73B-D51E-3339-AB5B-50AC78740FB8]@0xfffffe0016e04000->0xfffffe0016e13fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.AppleEmbeddedPCIE(1)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.ApplePIODMA(1)[A8EFA5BD-B11D-3A84-ACBD-6DB25DBCD817]@0xfffffe0016b0c000->0xfffffe0016b13fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff dependency: com.apple.iokit.IOThunderboltFamily(9.3.2)[11617399-2987-322D-85B6-EF2F1AD4A794]@0xfffffe0017d80000->0xfffffe0017e93fff Stackshot Succeeded Bytes Traced 277390 (Uncompressed 703968) ** System Information: Apple Silicon M1 BigSur 11.1 Model: Macmini9,1 Any help or suggestion is really appreciated. Thanks

I'm writing a software IOUserSCSIParallelInterfaceController in DriverKit — there's no DMA hardware behind it (it forwards commands elsewhere), so for each command I read the payload on the CPU by calling UserGetDataBuffer() from within my task-processing method and then CreateMapping() on the returned IOBufferMemoryDescriptor. This works almost all the time, but I've got an intermittent case I can't explain: for some WRITE tasks the buffer I get back is entirely zero-filled, even though it's a genuine write that should carry data. In those cases the SCSIUserParallelTask.fTransferDirection I'm handed is kSCSIDataTransfer_FromInitiatorToTarget, so the task itself looks like a perfectly normal write to me. It seems to happen when the same task object gets reused — a read on that task, then a write. I got stuck, so I disassembled IOSCSIParallelFamily to try to understand where the buffer comes from. In UserGetDataBuffer_Impl it looks like it allocates a fresh IOBufferMemoryDescriptor, zero-fills it, and only copies the client data in when the transfer direction is "from initiator to target". Roughly what I think I'm seeing: ; allocate a fresh IOBufferMemoryDescriptor, then bzero it bl GetDataTransferDirection ; SCSIParallelTask -> SCSITask (+0x100), then ldrb w0, [x0, #0x5b] cmp w0, #1 ; kSCSIDataTransfer_FromInitiatorToTarget ? b.ne Lskip ; if not a write, leave the buffer zeroed ... client->readBytes(0, bounce, len) ; copy client -> bounce Lskip: ... return bounce ; hand back the (possibly still-zeroed) buffer The direction it tests there is read from the SCSITask itself (the byte at SCSITask+0x5b, via GetDataTransferDirection), not from the fTransferDirection field I get in the task struct. And in the failing cases that byte still seems to hold the previous direction for that task (a read, 0x02), so the cmp w0, #1 doesn't match and the copy is skipped — which would explain the zero buffer. I could easily be misreading the disassembly, so I'd really appreciate a sanity check on the intended contract: Is UserGetDataBuffer the right way for a software (no-DMA) controller to get at write payload on the CPU at all? The docs frame it as the exception and otherwise point at fBufferIOVMAddr, but that reads like an IOVM/physical segment I don't think I can map for CPU access — is there a CPU-accessible path I'm missing? Is it my responsibility (or the layer above me) to make sure the task's data-transfer direction is established before UserGetDataBuffer runs? Is there something I should be doing at task setup / UserMapHBAData / completion so this direction isn't stale when a task object is recycled? Or is the SCSITask direction meant to always agree with fTransferDirection by the time my task-processing method runs, and a mismatch means I've done something wrong on my end? Any pointers on the intended behavior here would be a big help — thanks.

The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }

Can a Thunderbolt device dynamically expose logical child devices to macOS and control their connection and disconnection lifecycle, independently of the physical device connection?

One of the possible solutions to a problem that I'm working on is to have two Drivers loading in one DriverKit dext, an IOUserHIDEventService and an IOUserHIDDevice. For this to work, however, I need to have the event service send a message to the Device. IOKit has the service and connection objects that I can use just like an app would (just like the app the driver communication example). But DriverKit complains whenever I try to add the IOKit framework, saying that it is not supported. Is there another way that I can send a message directly from one driver to another?