I'm writing a C/C++ command line program which, at some point, calls IOHIDManagerOpen. I've added both my program executable and lldb as permitted for input monitoring (as far as I remember, my program was added after showing up a permission prompt, I've added lldb manually later, trying to resolve the problem). My problem is that when I run my program from within lldb in Terminal, the call to IOHIDManagerOpen returns kIOReturnNotPermitted. When I run my program directly in the terminal session (without lldb), this call returns kIOReturnSuccess. Such behaviour means it will be impractical to use lldb for any debugging of this program. What can be done to make lldb session behave the same way, the normal execution works? I'm on: 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020 arm64 and: lldb-1500.0.200.58 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)

When application requires apple reciepts, apple server returns 21107 satus. Why apple server return 21107?

Where do I get. PerfPowerTelemetryClientRegistrationService which is suddenly missing from my system since upgrading to MacOS15/IOS18?

I have a USBDriverKit driver which tries to send vendor-specific DeviceRequests to the IOUSBHostDevice. A few short months ago this worked, and as far as I know, the only change since it last worked is an update to macOS 14.5. The dext user client calls through to the driver, which wants to do this: ivars->mDevice->Open() ivars->mDevice->DeviceRequest() ivars->mDevice->Close() the problem is that the call to Open returns 0xe00002cde, which is kIOReturnNotOpen. If I don't call Open, but simply call DeviceRequest, I get the same result, kIOReturnNotOpen, which I would expect. I'm pretty sure that in macOS 14.4, the call to Open() did not return an error. I haven't seen any system logs that clue me in to why Open() is failing. It would be handy if the error gave me some reason why the device cannot be opened. Has anyone else seen this? I've searched high and low and I can't find any examples of dexts which actually do anything at all with a USB device.

Hello forum, I'm trying to build communications between a non-MFi HID device (say, a keyboard with a USB-C port) and an iOS device over a MFi-licensed cable with Swift, what framework would you suggest? The USB-C cable is MFi-licensed. The keyboard is not MFi-licensed.

I use NETransparentProxyProvider transparent proxy the outbound data ports 80 and 443, at the same time using CocoaAsyncSocket third party open source libraries for data forwarding At first, handleNewFlow will be called normally, but after running for a period of time, handleNewFlow will not be called again, and the system will not be able to access the Internet unless the vpn is disabled By checking the terminal app log, I found that handleNewFlow will not be called again when the following information is displayed. # Domain=NEAppProxyFlowErrorDomain Code=1 "The operation could not be completed because the flow is not connected" UserInfo={NSLocalizedDescription=The operation could not be completed because the flow is not connected" #

hi all. I subscribe the notify write event, every time I recieve a notify write event message i will send log data and reply block(didn't do nothing) with async method to host app(Objc XPC API).host app will reply immediately once it recieves data. after a while my sysext crashed, then I checked system log find the log below. launchd: exited with exit reason (namespace: 30 code: 0xc40000000004aaaa) - (unknown reason) is it because of exceeding the maximum limit of xpc's block queue length, or too many memory allocation, or... by the way, host app didn't crash. how this happened exactly? how could i solve it?

Hello. Is there a legal way to block iOS devices from being mounted on macOS? I noticed, that when an iOS device is connected, it pretends to be like a storage device but it is not. It not even going through diskArbitration. It seems that some fileProvider is taking place there. I know that it is possible to do via the MDM profile: <key>PayloadContent</key> <dict> <key>.GlobalPreferences</key> <dict> <key>Forced</key> <array> <dict> <key>mcx_preference_settings</key> <dict> <key>ignore-devices</key> <true/> </dict> </dict> </array> </dict> </dict> But is there some programmatic solution? If I use EndpointSecurity and block file operations for the usbmuxd process on /var folder, it prevents iOS devices from being mounted. But wouldn't be there any negative side effects from such a solution?

How do I adjust the latency timer for the AppleUSBFTDI driver? I am developing an app in Swift using Xcode on a MacBook Pro M1 running Big Sur, for clinical brain-computer interface (BCI) research. The app needs very low-latency streaming from an external USB device. The external device is a headset which connects via Bluetooth to an FT231X chip mounted on a USB-Serial dongle. The FT231X chip reads timestamped EEG data from the headset. The issue is that the AppleUSBFTDI driver is buffering the packets coming in from the headset, which causes jitter in the timestamps. Typically, with proprietary drivers from FTDI, the solution is to reconfigure them to reduce the latency timer to 1ms. The Info.plist is edited to add new key/value pairs. Is there a similar solution for Apple's built-in driver?

Hi everyone, first-time caller, long-ti... wait, no, I just got here. :) I am relatively new to all things Apple, so apologies in advance if it takes me a few goes to properly explain things. We have a framework, which includes an API, an XPC service, etc, and we have a device driver. We also have some sample apps that use the framework, and if they have the app sandbox capability, then we expect them to use the XPC Service instead of accessing our driver directly. This works fine on Monterey and presumably has worked fine on all previous versions of MacOS. Something seems to have changed on Ventura, and we don't understand what. When we build the same app on Ventura, it appears to be in the sandbox (according to the Sandbox column in Activity Monitor), but in the Console there is this line (twice): default <time> <OurAppName> Revoking sandbox extension; key = 0 Which we suspect is linked to the fact that the app then does not use the XPC Service, and instead accesses the driver directly, much to our surprise. Software built on developer's machines is "Automatically managed" and "Signed to Run Locally" in case that matters. Do we need to change our code to support Ventura and onward? Or is it a bizarre bug? Oh, I should say that I'm running the latest version of Ventura (13.6.7 as of writing) but not the latest Xcode (14.2 (14C18)) and CLI tools... can't remember how to find that version... Apple clang version 14.0.0 (clang-1400.0.29.202). Any help would be appreciated, thanks. Jeremy

How can a Dext be activated from C++. Specifically we need to load our Dext from our c++ CoreAudio server plugin. I guess it all boils down to how to call the OSSystemExtensionRequest Swift interface from C++... Thanks for any hints!

Hi. I am new to ios development and I am using swift to try to develop a sample app to connect a Canon camera to an iphone via a usb cable and I want to use the ImageCaptureCore framework to do this (that is I want to use the USB PTP). Although I see the documentation on the Apple site, I am still unsure where to begin. Is there any tutorials, etc. about where I can get started with this? I was able to find a couple of code snipets and piece together something with ICDeviceBrowser but when I load the program onto my iphone and connect the camera via usb, I am not able to detect any camera. So ideally I am looking for some sort of tutorial that goes through how to do this or if not, what do I have to do to at least be able to detect the camera from the iphone?

We have developed a library and a DriverKit driver on Mac platform. And we need to disable SIP to install dext and later point of time if we enable SIP then the dext is non functional. So is it mandatory to disable the SIP for whole life time of dext? Also it is not recommended to disable the SIP for a long time, as it may create a security hole. Standard ways are given on Apple support page that how to notarise an application to distribute over the internet. Here one mandatory account is required that is Apple Developer account which is a paid account we believe. Standing at this point can you share the complete steps of software distribution process which will include code signing, notarisation process and stapling.

Using IOServiceMatching and IOServiceGetMatchingServices api's written in swift to extract the info of both internal and external USB devices connected. For the same code Intel based Mac OS devices gives all the info like product id , vendor id , Serial number and etc for both external and Internal USB devices( Apple and Non Apple devices connected either to Apple T2 bus or USB bus). For the same code M2 Mac Machine only gives the external device info which are connected to USB, doesn't give any info of Internal USB connected devices. Why is this difference ? Which api's need to be used to extract info of internal USB connected devices even in M2 based Mac machine. Thanks

The only one I can find it are some code comments in head files, would like to know any detialed workflow or sample code for it. Thanks!

I am using SCSIPeripheralsDriverKit/IOUserSCSIPeripheralDeviceType00 to develop a Dext driver, which has only two classes: MyUserSCSIPeripheralDeviceType00 and MyUserClient, MyUserClient is responsible for receiving APP commands and passing them to MyUserSCSIPeripheralDeviceType00->UserSendCDB(), After the device is connected to the computer, the driver can match the device and start, calling MyUserSCSIPeripheralDeviceType00-->init(), MyUserSCSIPeripheralDeviceType00-->Start(), Any command sent by the APP to MyUserSCSIPeripheralDeviceType00 will return a failure: kIOReturnUnsupported (0xe00002c7), including UserSendCDB(), UserReportMediumBlockSize(), <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>IOKitPersonalities</key> <dict> <key>MySCSIDriver</key> <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleIdentifierKernel</key> <string>com.apple.kpi.iokit</string> <key>IOClass</key> <string>IOUserService</string> <key>IOMatchCategory</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOProviderClass</key> <string>IOSCSIPeripheralDeviceNub</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOUserClass</key> <string>MyUserSCSIPeripheralDeviceType00</string> <key>IOUserServerName</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>MyUserClient</string> </dict> <key>bConfigurationValue</key> <integer>1</integer> <key>bInterfaceNumber</key> <integer>0</integer> <key>bcdDevice</key> <integer>1</integer> <key>idProduct</key> <string>*</string> <key>idVendor</key> <integer>12345</integer> <key>Peripheral Device Type</key> <integer>0</integer> <key>IOKitDebug</key> <integer>65535</integer> </dict> </dict> </dict> </plist> This is the method that receives client calls kern_return_t MyUserSCSIPeripheralDeviceType00::HandleExternalStruct(IOUserClientMethodArguments* arguments) { kern_return_t ret = kIOReturnSuccess; SCSIType00OutParameters command; SCSIType00InParameters response; SCSI_Sense_Data sense; UInt64 fSenseAddr = (intptr_t)&sense; bzero((void *)&command, sizeof(SCSIType00OutParameters)); bzero((void *)&response, sizeof(SCSIType00InParameters)); bool test = TEST_UNIT_READY(&command, &response, fSenseAddr); // test is true ret = this->UserSendCDB(command, &response); // ret is kIOReturnUnsupported （0xe00002c7） UInt64 blockSize; kern_return_t sizeRet = this->UserReportMediumBlockSize(&blockSize); // sizeRet is kIOReturnUnsupported （0xe00002c7） }; // Not called. As per the documentation, this should be called during enumeration. kern_return_t IMPL(I4UserSCSIPeripheralDeviceType00, UserDetermineDeviceCharacteristics) { // *result = true; return kIOReturnSuccess; }

Hi, does anyone know if IOUSBDeviceInterface187 and IOUSBInterfaceInterface190 interfaces will be available on application level next years and there is no any deprecation plans ? Common Recommendations are to use USBDriverKit, but is there a real need to complicate USB communication in this way?

I am attempting to communicate over serial with a USB-C device and an M-Series iPad. I have proven the device to communicate as expected (baud rate, parity, etc) via a Swift app on Mac using a third party library (IOKit) that utilizes the "AppleUSBACM (v5.0.0)" driver on macOS. I am looking to recreate this communication via iPadOS and a custom DriverKit driver that provides this same interface. There is not an example from Apple for serial communication and DriverKit but there is a couple for communicating from an app to the dext, and for other networking examples. There are also other mentions in WWDC videos but they are incomplete and do not provide the needed structure. Communicating between a driver extension and a client app Connecting a network driver Bring your driver to iPad with DriverKit System Extensions and DriverKit My question revolves around architecture and how to set up a driver for these needs. I have gotten the examples to run and understand what is needed for entitlements and other local signing needs. But what I don't understand is if you need a basic setup similar to the "Communicating between a driver extension and a client app" where your base driver subclasses IOService and has two arms. One that subclasses IOUserclient and allows communication between the dext and your Swift app. And another arm that subclasses IOUserSerial or IOUserUSBSerial. I assume then that these two share buffers of memory set up by the base class that allows communication between the two. I have had little luck getting IOUserUSBSerial to compile and have made more progress on IOUserSerial. But when running that and with the supposed idVendor plist entry I am not getting that part of the dext to start or recognize when the USB device is plugged in. Long story short, I'm looking for a basic architecture or example reference to explain serial communication in DriverKit. Devices: Custom USB-C hardware that is CDC ACM compliant iPad Air 5th gen with M1 chip (iPadOS 17.2) M1 MBP (macOS 14.2.1)

Hardware and software configuration MacBook Air M2 2022 16GB, MacOS Ventura 13.2.1 Full description This is a DriverKit that controls PCIE FPGA devices for low-latency data exchange. This driver has been implemented on Iokit, and now it needs to be launched on Driverkit to adapt to newer Macs. Driverkit lacks the IOMemoryDescriptor::withAddressRange(Iokit) function to convert the app's memory of any size to a Descriptor. Currently, we use args->structureOutputDescriptor->CreateMapping to map the Descriptor passed by the application to the kernel layer. // App size_t ***::xxRead(long long addr, size_t size, void * buff){ std::lock_guard<std::mutex> guard(usrLock); kern_return_t kr; uint64_t info[2] = {(uint64_t)addr, (uint64_t)size}; kr = IOConnectCallMethod( connect, kUserReadIO, info, 2, NULL, NULL, NULL, NULL, buff, &size); return size; } // Driverkit const IOUserClientMethodDispatch sMethods[kNumMethods] = { [kUserReadIO] = { (IOUserClientMethodFunction) &SmiPcieUc::sUserReadIo, .checkCompletionExists = false, .checkScalarInputCount = 2, // Read Addr, size .checkStructureInputSize = 0, .checkScalarOutputCount = 0, .checkStructureOutputSize = kIOUserClientVariableStructureSize} // Read Data }; kern_return_t SmiPcieUc::sUserReadIo (OSObject * target, void* reference, IOUserClientMethodArguments* args){ IOMemoryMap * memMap = nullptr; uint32_t * buffKptr = nullptr; kern_return_t rt = 0; if(target == nullptr){ Log("***Err***: sUserReadIo Target is Null!"); return kIOReturnError; } if(args->structureOutputDescriptor){ rt = args->structureOutputDescriptor->CreateMapping(0,0,0,0,0, &memMap); if(rt == kIOReturnSuccess){ buffKptr = reinterpret_cast<uint32_t *>(memMap->GetAddress()); } else { Log("***Err***: sUserReadIo Mapping Failed!"); return kIOReturnNoMemory; } } else { buffKptr = (uint32_t *) args->structureOutput; } rt = ((SmiPcieUc *)target)->UserReadIo((uint64_t *)&args->scalarInput[0], (size_t *)&args->scalarInput[1], buffKptr); OSSafeReleaseNULL(memMap); return rt; } phenomenon When StructureOutputSize is greater than 4096, args>structureOutputDescriptor exists, and when it is less than or equal to 4096, args->structureOutputDescriptor and args->structureOutput are both equal to nullptr, (in IOkit, args->structureOutput is not empty)。 How to properly convert any size of application memory into the kernel space of Driverkit？

The link is as follows: app store: monitor+ I have checked the header file for USB in the IOKit framework of macOS, but it does not exist in iOS. Is it necessary to collaborate with Apple to implement functions similar to monitor+(PTP control camera)?