I have an app with a dext, which I developed using Xcode 13.4.1. I used to sign it manually using our Developer ID Distribution certificate and profile, because Xcode 13 didn't support automatic dext signing, and most of my problems stemmed from signing or entitlement configuration problems, not coding problems, so I never used 'sign to run locally'. I tried to build the same app & extension with Xcode 14; the build fails with this helpful error: Xcode 14 and later requires a DriverKit development profile enabled for IOS and macOS. Visit the developer website to create or download a DriverKit profile So I went to the portal, selected the DriverKit App Development profile type, selected my App ID, selected my development certificate, selected all my test devices, selected my entitlements, named it, clicked Generate - and nothing happens. The "Generate" button title briefly changes to "Processing...", but I can't see how to get to the Download stage. Anyone have any idea what I'm doing wrong?

I'm trying to build the DriverKit template driver target in an Xcode project which contains an app targeting iPadOS 17. I've made no modifications to the DriverKit template. When building, I get this link error ld: file cannot be open()ed, errno=2 path=/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a in '/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a' anyone know how to fix this? My search turned up something about building llvm from sources, which seems like overkill to put a DriverKit driver into an iPad app.

I'm struggling to build a driver for iPadOS in a particular project configuration. If I put the driver code and dext target into the same Xcode project which contains the iPad app, all is well. This is the way the Xcode driver template does it. However, I'd like to build and debug the dext on macOS, while eventually deploying on iPadOS. So I put the dext into a different project, which has a macOS target, a minimal iPadOS target and a DriverKit target. I made a workspace which contains both projects. I dragged the macOS project into the iPadOS project so that I can refer to the products of the macOS project (specifically, its driver target) as a dependency of the iPadOS target. Note that the main iPad app target depends on the driver target. So the workspace organization looks like this: Workspace iPad project main iPad app target (depends on driver) test project reference test project test macOS/iPad app target DriverKit dext target When I build the iPadOS target, it builds the dependent driver target in the macOS project, but it fails to link because Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a is not found. If I just build the driver target directly in Xcode, there is no such complaint. I looked closely at the build logs, and I see for the failed link, there are these two linker flags set which are not set in the successful case -debug_variant -fprofile-instr-generate I can't seem to control the generation of this flag. I tried turning off the Profile switch in the Scheme editor for the driver, but is makes no difference. When I directly build the driver target, no -fprofile-instr-generate is set and it compiles and links. When i build the driver as a dependency of another target, -fprofile-instr-generate is passed to the linker, which fails. The obvious workaround is to put the driver source code into a separate driver target in the iPadOS project, but I'd rather have just one DriverKit driver for both platforms, with a few settings (such as bundle ID) controlled by a configuration file. Has anyone else encountered this problem, and know of a workaround?

The presentation "create audio drivers with DriverKit" from WWDC 2021 demonstrates how to use a dext to implement a virtual audio driver. It also says " If a virtual audio driver or device is all that is needed, the audio server plug-in driver model should continue to be used". Indeed, in AudioDriverKit/AudioDriverKitTypes.h, there is no IOUserAudioTransportType Virtual, although CoreAudio/AudioHardwareBase.h includes kAudioDeviceTransportTypeVirtual. For one of our products, we require virtual devices to implement a software loopback "cable". We've implemented this using the "traditional" HAL plugin, and as a proof-of-concept, also using a dext. In the dext, I tried setting the transport type to 'virt', which seems to only have the effect of changing the icon shown in Audio Midi Setup. HAL plugins require an installer, and the installer has to kill coreaudiod in a post-install script. You have to turn off SIP to debug them. Just like AudioDriverKit drivers, they are out-of-process and run in a process not owned by the hosting app. Our HAL plugin's interface is property based; we had to write a lot of boiler-plate code to implement required properties. Writing an AudioDriverKit driver is in most respects easier - a lot of the scaffolding is implemented in the base driver, which we only alter where required. Debugging and installation is much easier. The dext works just fine, as far as we can ascertain, just as well as a HAL plugin. So, my question is - is the advice to use a HAL plugin for a virtual device still correct in 2025? And if so, what's the objection? We'd really prefer to ship the AudioDriverKit virtual audio device.

I've made a dext and a user client that overrides IOUserSCSIPeripheralDeviceType00, with the object of writing device firmware to the driver. I can gain and relinquish exclusive access to the device, I can call UserReportMediumBlockSize and get back a sensible answer (512). I can build command parameters with the INQUIRY macro from IOUserSCSIPeripheralDeviceHelper.h and send that command successfully using UserSendCB, and I receive sensible-looking Inquiry data from the device. However, what I really want to do is send a WriteBuffer command (opcode 0x3B), and that doesn't work. I have yet to put a bus analyzer on it, but I don't think the command goes out on the bus - there's no valid sense data, and the error returned is 0xe00002bc, or kIOReturnError, which isn't helpful. This is the code I have which doesn't work. kern_return_t driver::writeChunk(const char * buf, size_t atOffset, size_t length, bool lastOne) { DebugMsg("writeChunk %p at %ld for %ld", buf, atOffset, length); SCSIType00OutParameters outParameters; SCSIType00InParameters response; memset(&outParameters, 0, sizeof(outParameters)); memset(&response, 0, sizeof(response)); SetCommandCDB(&outParameters.fCommandDescriptorBlock, 0x3B, // byte 0, opcode WriteBuffer command lastOne ? 0x0E : 0x0F, // byte 1 mode: E=save deferred, F = download and defer save 0, // byte 2 bufferID (atOffset >> 16), // byte 3 (atOffset >> 8), // byte 4 atOffset, // byte 5 (length >> 16), // byte 6 (length >> 8), // byte 7 length, // byte 8 0, // control, byte 9 0, 0, 0, 0, 0, 0); // bytes 10..15 outParameters.fLogicalUnitNumber = 0; outParameters.fBufferDirection = kIOMemoryDirectionOut; outParameters.fDataTransferDirection = kSCSIDataTransfer_FromInitiatorToTarget; outParameters.fTimeoutDuration = 1000; // milliseconds outParameters.fRequestedByteCountOfTransfer = length; outParameters.fDataBufferAddr = reinterpret_cast<uint64_t>(buf); uint8_t senseBuffer[255] = {0}; outParameters.fSenseBufferAddr = reinterpret_cast<uint64_t>(senseBuffer); outParameters.fSenseLengthRequested = sizeof(senseBuffer); kern_return_t retVal = UserSendCDB(outParameters, &response); return retVal; }

I made a CMIOExtension (a virtual camera) which generates its own output, for use in our in-house software testing. I wanted to make a video source with 29.97, 30, 59.94 and 60fps output. To this end, I created a CMIOExtensionDeviceSource which creates a CMIOExtensionDevice with one CMIOExtensionStreamSource with various stream formats contained in [CMIOExtensionStreamFormat], including one with both maxFrameDuration and minFrameDuration = CMTimeMake(value: 1000, timescale: 30000) and another with both maxFrameDuration and minFrameDuration = CMTimeMake(value: 1001, timescale: 30000) I've held off on the creation of the 59.94/60fps source for now until this problem is resolved. my virtual camera works, it produces a signal, but when I examine its associated AVCaptureDevice in the debugger, I find (lldb) po self.captureDevice?.formats[0].videoSupportedFrameRateRanges[0].maxFrameDuration ▿ Optional<CMTime> ▿ some : CMTime - value : 1000000 - timescale : 30000000 ▿ flags : CMTimeFlags - rawValue : 1 - epoch : 0 I get the same value, 1000000/30000000, or exactly 30fps, for all the formats of my AVCaptureDevice. Is there something I'm doing wrong, or do CMIOExtensionDevices always round the frame rates? I can't force CoreMediaIO to produce frames at exactly my desired frame interval, but I'd like to ensure that the average frame rate is my desired rate. How can I do that? Frame emission is governed by a repeating DispatchSourceTimer with a repeat time specified in nanoseconds with the TimerFlags set to 'strict'.

The "deployment target" for a DEXT is a number like 19.0 or 21.4. Xcode seems to pick the latest version on the machine you are creating the target on as a default - so if I make a new Driver target on Xcode 14 and Ventura, the Deployment Target for the driver will be 21.4. If I'm targeting macOS 12 (for example), what version of DriverKit should I choose, and where is this documented?

I have a macOS app which contains a dext. I'd like to distribute it to external testers using TestFlight, so it has to pass Mac App Store review. It failed, because the App Sandbox entitlement was missing. I checked the app, it has the entitlement, but the dext does not. However, the .entitlements file used by the dext does contain App Sandbox set to true. I tried adding a "fake-entitlement" value to the .entitlements file, and that made it into the dext's code signature, but the App Sandbox entitlement appears to be stripped out by the build process? For a dext target, it isn't possible to add the App Sandbox capability in Xcode's Signing and Capability section. I have to add the entitlement manually in the .entitlement file (or it was put there by the Xcode driver template, I don't remember). I've tried clean building several times, I've tried Xcode 15.0.1, 15.2 and 15.3, but the result is always the same. I'm inspecting the entitlements using codesign -dvvv --entitlements - Does anyone know what I can do to put the App Sandbox entitlement into my dext's signature? Is this happening to anyone else?

I'm trying to implement an app Shortcut (Custom Intent) for a macOS app on Monterey. Shortcuts.app finds the shortcut, but when I run it, the progress bar goes to 50% and stops. My handler and resolution code is not called. I'm implementing the handling in-app (not in an extension) I'm following instructions from the WWDC 2021 video "Meet Shortcuts for macOS" and this link https://developer.apple.com/documentation/sirikit/adding_user_interactivity_with_siri_shortcuts_and_the_shortcuts_app?language=objc If I filter on "shortcuts" in the Console app, and press the run button in Shortcuts.app for my Shortcut, I see this message (amongst others) -[WFAction processParameterStates:withInput:skippingHiddenParameters:askForValuesIfNecessary:workQueue:completionHandler:]_block_invoke Action <WFHandleCustomIntentAction: 0x15c1305b0, identifier: finished processing parameter states. Values: which looks sort of promising but I also see this Sandbox: Shortcuts(9856) deny(1) file-read-data /Users/stu/Library/Developer/Xcode/DerivedData/-hghdaydxzeamopexvfsgfeuvsejw/Build/Products/Debug/.app I've tried moving my app to /Applications and launching it from there, I see a similar message in the log, but the path leads to the app in /Applications. I've tried deleting all copies of my app aside from the one I'm currently building and debugging. I've tried deleting the derived data folder, restarting the Mac, re-launching the Shortcuts app. I've tried sandboxing my app. Other Shortcuts (for other apps) work on this machine. I'm probably missing something extremely simple - does anyone have a suggestion? Some related questions: At WWDC 2022, Apple introduced "App Intents", without adequately explaining how these differ from the intents described in the WWDC 2021 video. Can anyone tell me what the difference is? In the Xcode editor for the .intentdefinition file, there's a button "Convert to App Intent". Clicking it produces some new Swift files in my app, but the thing is an intent handled by an app, and now it is an App Intent - what's the difference? Is one better than the other? Do I have to click the convert button again if I subsequently modify the .intentdefinition file, or is this conversion process intended to replace the .intentdefinition file with those .swift files?