Hi. Welcome to these forums, which are for developers to communicate with other developers (some of whom may work for Apple) about issues with developing software for Apple platforms. You're not going to get much traction here. Your issue seems to be a feature suggestion for Apple software. Apple have a web address where you can submit such feedback: https://www.apple.com/feedback/ It helps if you clearly identify what platform (macOS, iOS, iPadOS, watchOS, tvOS...) you are referring to, and clearly describe what feature you think is missing (close all what?). If you believe you have found a bug in Apple software, you can use this address: https://feedbackassistant.apple.com or the Feedback Assistant app.

This has often happened to me with code which is incorrect but not glaringly so. I've found that using an LLM is useful here. Just ask it "why can't the Swift compiler type check this in reasonable time: " and append the code. An LLM isn't as hard-nosed as a compiler; it can spot common errors like extra or missing commas. It might be worth suggesting this as an Xcode feature. Just as the compiler constantly runs in the background as you type, an LLM could constantly examine your code and point out oddities - things that might even compile, but are likely unintended, or possible reasons for compiler error messages.

look in ~/Library/Developer/Xcode/UserData/Provisioning Profiles for the Xcode-generated profile. You can use QuickLook to inspect the profile. If you added the DriverKit USB (development) Capability, your profile should have idVendor='*'. This wildcard value will only work for development builds. Your entitlements.plist should have an entry called com.apple.developer.driverkit.transport.usb or "DriverKit USB Transport' which is an array, containing one or more items, each of which is a dictionary. Each dictionary should have an item with key idVendor and value a decimal number equal to the vendor ID of the device you're driving.

Well, welcome. Most Apple documentation is a reference of API calls, generated from header files. It tells you how to spell them, what the parameters are, sometimes what those parameters mean, what OS versions you can use them in, and not much else. Learning from these resources is like trying to learn a natural language from a dictionary. Apple has some videos from WWDC presentations about new technologies, but these tend to assume familiarity with the language and the problem domain. In the olden days (maybe twenty years ago), I might have said "get a book", but books are out of date the moment they are written. If you have access to an AI, I can recommend this approach. Prompt it with a program you have written in Python. Tell it that you are a Python programmer, and you are new to Swift, and that it should translate the program to Swift, and explain what it does and how the code compares to the Python implementation. Ask it to provide links to relevant documentation. Then read the explanation it provides, follow the links, read those. Try out the code (remember, AI makes mistakes, confidently). There are also a lot of good resources on the web. If you're stuck with how to use a particular API, search for " example". Pretty soon you'll identify some sites you will want to return to again and again. Good luck!

We parse the locationID out of the AVCaptureDevice.uniqueID and then find the IORegistry node with that locationID. Is there's a document declares how AVFoundation generate the unique_id for USB camera, no so I can assume this convert will always work? you can't Or is there's a way to send a PTZ control request to AVCaptureDevice? not that I know of. As far as I know, the only way is what you're doing. It looks that the unique_id provided is (locationID<<32|VendorID<<16|ProductID) as hex string, but I'm not sure if I can always assume this behavior won't change. Correct - it has changed in the past, it might change at any time in the future. Not all AVCaptureDevices are UVC, but they all have uniqueIDs. If you would like an API to clearly identify an AVCapture device in the IORegistry, please file a bug. I already did (in 2019, FB6146541)

are you using IOServiceGetMatchingService("DriverKitAcxxx") as shorthand for let dict = IOServiceNameMatching("DriverKitAcxxx") service = IOServiceGetMatchingService(kIOMainPortDefault, dict) and did you call RegisterService from your driver code?

Just to let you know, FB19449747 has been fixed, so there is now a development-only entitlement for PCI DriverKit. I was asked to follow up on FB19449747 after this was supposedly fixed, so I did. I can't see a DriverKit PCI Transport (development) entitlement in the list of available Capabilities.

Hi David you can use the Feedback Assistant app on macOS, or https://feedbackassistant.apple.com to log a trackable bug, which you can assign to your self or your development team (if you are a member of one). That other link seems to be for anonymous user feedback.

are you developing for macOS or iPadOS, or both? com.apple.developer.driverkit.communicates-with-drivers is for iPadOS. It won't do any harm to set this to true in a macOS app, but you don't need it. When you say your driver "fails at runtime", there are various ways this can occur: it fails to load (perhaps due to an entitlement issue), your code fails to find the driver your code finds the driver, but fails to open a user client for it It sounds like you're failing at stage 2. Look in the system log for messages related to your driver's bundle ID. I like to plug in the device, then run log collect --last 1m and peruse the resulting log file in the Console app. Use IORegistryExplorer (part of the additional tools for Xcode) to look for your driver in the IORegistry. If it isn't there, IOServiceGetMatchingService won't find it. IOServiceGetMatchingService takes a matching dictionary as a parameter, but you said you are calling IOServiceGetMatchingService("DriverKitAcxxx") Did you mean IOServiceNameMatching, or IOServiceGetMatchingService and you are passing in a dictionary created with CreateNameMatchingDictionary? Or something else? If you're using a matching dictionary, compare its contents carefully with the properties of your driver. Not that the name of the service is not a property called "name" (or at least, IORegistryExplorer doesn't display it as such). I like to use IOServiceNameMatching with a unique name (i.e. in your case I'd choose "com.accusys.Acxxx.driver"). Then, in your driver's Start_Impl, before you call RegisterService, call SetName("com.accusys.Acxxx.driver"). This enables you to write a generic name for your driver's class like "driver", while having a unique name to look for the in IORegistry.

most of the information you're looking for is in the support article you linked to. You probably want to scroll down this page and follow the directions to apply to the MFi program. https://mfi.apple.com

go to ~/Library/Developer/Xcode/UserData/Provisioning Profiles and use QuickLook to inspect the Xcode-generated .provisionprofile file for your app, to be sure that its com.apple.developer.driverkit.userclient-access claim is correct. in the meantime, you could set com.apple.developer.driverkit.allow-any-userclient-access to true in your driver.

I uploaded the requested IORegistryExplorer files. I also note a couple of other things: every time I re-attach the device, I get a new driver process and a new IOUserServer at the root of the IORegistry. Even if I delete the app the existing driver process keeps running, unless I kill it from Activity Monitor. Maybe there's something I'm not cleaning up properly, but I don't know what. when I eject the disk, there is a very perceptible delay between ejecting the volume and its associated - Data container. I use Finder/Settings and check the External Disks item in the Sidebar/Locations list. After I click the eject control next to the volume, I unplug the device as soon as it disappears from the sidebar, and very often see a notification about ejecting "volume - data" when it wasn't ready to be ejected. If I keep /Volumes open I can see that "Volume"'s icon disappears first, then "Volume - Data"'s icon. Is this a bug worth filing?

I've often used serial-to-USB converters connected to a Mac, and not had reliability problems with them. I like to use the Silabs CP2104. Silicon Labs have drivers for these for various platforms. Your code need to know the /dev name of the serial device, which you can derive by inspection in your case (just plug it in, install the driver, list /dev). To get things going, you can use a terminal emulator like CoolTerm. The Modbus RTU protocol is well described in the documentation you linked. If I were you, I'd make a command line tool written in Python which reads one displacement value from the voltmeter. I'd utilize that tool into my app's bundle and call it from there. Since I don't use Python very often and the problem is simple, I'd ask an LLM to write the program for me. you said although the instrument is displaying 0.000 volts, the data collected changes at each message I send to the instrument, proving me that Modbus RTU set up is not working. but what does the data you collected actually represent? (I didn't read the docs in enough depth to decode the hex data you show). It seems like you have nearly all the pieces you need already. Obviously you already have some form of interface to the voltmeter, you just have to replace the Modbusrtubusmaster you mentioned with your own code.

Filed FB20382589

Thank you once again Kevin! I filed a bug against the documentation: FB20379178 Now that I'm using uint8_t senseBuffer[20] = {0}; I run into a new problem. I started a new thread on it: https://developer.apple.com/forums/thread/802099