The online documentation for fs_snapshot_create, which is on a website which apparently I'm not allowed to link to on this forum, mentions that some entitlement is necessary, but doesn't specify which one. Searching online I found someone mentioning com.apple.developer.vfs.snapshot, but when adding this to my entitlement file and building my Xcode project, I get the error Provisioning profile "Mac Team Provisioning Profile: com.example.myApp" doesn't include the com.apple.developer.vfs.snapshot entitlement. Searching some more online, I found someone mentioning that one has to request this entitlement from DTS. Is this true? I couldn't find any official documentation. I actually want to make a snapshot of a user-selected directory so that my app can sync it to another volume while avoiding that the user makes changes during the sync process that would make the copy inconsistent. Would fs_snapshot_create be faster than traversing the chosen directory and creating clones of each nested file with filecopy and the flag COPYFILE_CLONE? Although I have the impression that only fs_snapshot_create could make a truly consistent snapshot.

ICEcard app is "Emergency as a Service" platform. One of the key feature is to know about primary info, health info, or in case missing child , elderly using Face scan of registered user of app via another registered user of ICEcard app. App was working fine but last 2-3 week back got issue reported of app getting closed as soon Face scan option is selected. to simulate issue > register > open face scan icon at bottom home screen> select any of option accident or health issue or information >> app closes immediately. Android app is working fine. link of app store. https://apps.apple.com/in/app/ice-card-app/id6736453602 android link for reference https://play.google.com/store/apps/details?id=com.rannlab.ice_card.ice_card&pcampaignid=web_share

I have an app that uses CKShare to allow users to share CloudKit data with other users. With the first build of the iOS 26, I'm seeing a few issues: I'm not able to add myself as a participant anymore when I have the link to a document. Some participants names no longer show up in the app. Looking at the release notes for iOS & iPadOS 26 Beta, there is a CloudKit section with two bullets: CloudKit sharing URLs do not launch third-party apps. (151778655) The request access APIs, such as CKShareRequestAccessOperation, are available in the SDK but are currently nonfunctional. (151878020) It sounds like the first issue is addressed by the first bullet, although the error message makes me wonder if I need to make changes to my iCloud account permissions or something in order to open it. It works fine in iOS 18.5. This is the error I get when I try to open a link to a shared document (I blocked out my email address, which is what was in quotes): As far as the second issue, I am really confused about what is going on. Some names still show up, while others do not. I can't find a pattern, and the missing users are not on the iOS 26 beta. The release notes mention CKShareRequestAccessOperation being nonfunctional, which is new in the beta and has some minor documentation, but I can't find information about how it's supposed to be used yet. In previous years there have been WWDC sessions about what's new in CloudKit, but I haven't found anything that talks about these changes to document sharing. Is there a guide or session somewhere that I'm missing? Does anyone know what's going on with these changes to CloudKit?

If I go to "System Settings" -> "General" -> "About", it says "MacBook Air" and below that "M2, 2022" How can I get these strings programatically? The following C code gets me #include <stdio.h> #include <sys/sysctl.h> int main() { static const unsigned namelen = 2; int name[namelen] = {CTL_HW, HW_PRODUCT}; char buffer[256]; size_t bufferSize = sizeof(buffer); if (0 != sysctl(name, namelen, buffer, &bufferSize, NULL, 0)) { perror("sysctl"); return 1; } printf("%s\n", buffer); } the string "Mac14,2", which is the hardware model identifier. But I want to get the user-friendly model name, e.g. "MacBook Air (13-inch, M2, 2022)". How can I do this?

I am looking for inputs to better understand MacOS entitlements. I ask this in context of OpenJDK project, which builds and ships the JDK. The build process makes uses of make tool and thus doesn't involving building through the XCode product. The JDK itself is a Java language platform providing applications a set of standard APIs. The implementation of these standard APIs internally involves calling platform specific native library functions. In this discussion, I would like to focus on the networking functions that the implementation uses. Almost all of these networking functions and syscalls that the internal implementation uses are BSD socket related. Imagine calls to socket(), connect(), getsockopt(), setsockopt(), getaddrinfo(), sendto(), listen(), accept() and several such. The JDK that's built through make is then packaged and made available for installation. The packaging itself varies, but for this discussion, I'll focus on the .tar.gz archived packaging. Within this archive there are several executables (for example: java, javac and others) and several libraries. My understanding, based on what I have read of MacOS entitlements is that, the entitlements are set on the executable and any libraries that would be loaded and used by that executable will be evaluated against the entitlements of the executable (please correct me if I misunderstand). Reading through the list of entitlements noted here https://developer.apple.com/documentation/bundleresources/entitlements, the relevant entitlements that an executable (like "java") which internally invokes BSD socket related syscalls and library functions, appear to be: com.apple.security.network.client - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.network.client com.apple.security.network.server - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.network.server com.apple.developer.networking.multicast - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.multicast Is my understanding correct that these are the relevant ones for MacOS? Are there any more entitlements that are of interest? Would it then mean that the executables (java for example) would have to enroll for these entitlements to be allowed to invoke those functions at runtime? Reading through https://developer.apple.com/documentation/bundleresources/entitlements, I believe that even when an executable is configured with these entitlements, when the application is running if that executable makes use of any operations for which it has an entitlement, the user is still prompted (through a UI notification) whether or not to allow the operation. Did I understand it right? The part that isn't clear from that documentation is, if the executable hasn't been configured with a relevant entitlement, what happens when the executable invokes on such operation. Will the user see a UI notification asking permission to allow the operation (just like if an entitlement was configured)? Or does that operation just fail in some behind the scenes way? Coming back to the networking specific entitlements, I found a couple of places in the MacOS documentation where it is claimed that the com.apple.developer.networking.multicast entitlement is only applicable on iOS. In fact, the entitlement definition page for it https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.multicast says: "Your app must have this entitlement to send or receive IP multicast or broadcast on iOS. It also allows your app to browse and advertise arbitrary Bonjour service types." Yet, that same page, a few lines above, shows "macOS 10.0+". So, is com.apple.developer.networking.multicast entitlement necessary for an executable running on MacOS which deals with multicasting using BSD sockets? As a more general comment about the documentation, I see that the main entitlements page here https://developer.apple.com/documentation/bundleresources/entitlements categorizes some of these entitlements under specific categories, for example, notice how some entitlements are categorized under "App Clips". I think it would be useful if there was a category for "BSD sockets" and under that it would list all relevant entitlements that are applicable, even if it means repeating the entitlement names across different categories. I think that will make it easier to identify the relevant entitlements. Finally, more as a long term question, how does one watch or keep track of these required entitlements for these operations. What I mean is, is it expected that application developers keep visiting the macos documentation, like these pages, to know that a new entitlement is now required in a new macos (update) release? Or are there other ways to keep track of it? For example, if a newer macos requires a new entitlement, then when (an already built) executable is run on that version of macos, perhaps generate a notification or some kind of explicit error which makes it clear what entitlement is missing? I have read through https://developer.apple.com/documentation/bundleresources/diagnosing-issues-with-entitlements but that page focuses on identifying such issues when a executable is being built and doesn't explain the case where an executable has already been shipped with X entitlements and a new Y entitlement is now required to run on a newer version of macos.

We would be creating N NWListener objects and M NWConnection objects in our process' communication subsystem to create server sockets, accepted client sockets on server and client sockets on clients. Both NWConnection and NWListener rely on DispatchQueue to deliver state changes, incoming connections, send/recv completions etc. What DispatchQueues should I use and why? Global Concurrent Dispatch Queue (and which QoS?) for all NWConnection and NWListener One custom concurrent queue (which QoS?) for all NWConnection and NWListener? (Does that anyways get targetted to one of the global queues?) One custom concurrent queue per NWConnection and NWListener though all targetted to Global Concurrent Dispatch Queue (and which QoS?)? One custom concurrent queue per NWConnection and NWListener though all targetted to single target custom concurrent queue? For every option above, how am I impacted in terms of parallelism, concurrency, throughput &amp; latency and how is overall system impacted (with other processes also running)? Seperate questions (sorry for the digression): Are global concurrent queues specific to a process or shared across all processes on a device? Can I safely use setSpecific on global dispatch queues in our app?

In my app the user can select a source folder to be synced with a destination folder. The sync can also happen in response to a change in the source folder detected with FSEventStreamCreate. If the user unzips an archive in the source folder and the sync process begins before the unzip operation has completed, the sync can fail because of a "Permission denied" error. I assume this is related to the posix permissions of the extracted folder being 420 during the unzip operation and (in my case) 511 afterwards. Is there a way to detect than an unzip operation is in progress and wait until it has completed? I thought that using NSFileCoordinator would solve this issue, but unfortunately it's not the case. Since an unzip operation can last any amount of time, it's not ideal to just delay a sync by a fixed number of seconds and let the user deal with any error if the unzip operation takes longer. let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true if openPanel.runModal() == .cancel { return } let url = openPanel.urls[0].appendingPathComponent("extracted", isDirectory: false) var error: NSError? NSFileCoordinator(filePresenter: nil).coordinate(readingItemAt: url, error: &error) { url in do { print(try FileManager.default.attributesOfItem(atPath: url.path).sorted(by: { $0.key.rawValue < $1.key.rawValue }).map({ ($0.key.rawValue, $0.value) })) try FileManager.default.contentsOfDirectory(at: url, includingPropertiesForKeys: nil) } catch { print(error) } } if let error = error { print("file coordinator error:", error) }

Hi, We are developing an app using PacketTunnelProvider from Network Extension framework. It is packaged as a system extension. We are trying to implement an "always-on" functionality, but cannot manage to start the extension before user login, with or without on-demand enabled. However we see in other posts (1, 2) that a network extension packaged as sysex should automatically start before user login. Are we missing something? Is it a limitation of PacketTunnelProvider? Thanks

I am encountering an issue with my application, BloxOneEndpoint.pkg, which includes two services: rc_service_infoblox – Runs as the root user. Controller Application – Runs as a normal user. Although a thread within rc_service_infoblox is running fine and performing its expected tasks, I notice that the service appears as "Not Responding" in Activity Monitor. Despite normal functionality, this status is concerning, as it may indicate some issue to customer. I would appreciate any insights into why this might be happening and how to resolve it. Is there a specific API or mechanism I should use to ensure the service remains in a "Running" state in Activity Monitor? Thank you for your guidance.

My team has developed an app with a Matter commissioner feature (for own ecosystem) using the Matter framework on the MatterSupport extension. Recently, we've noticed that commissioning Matter devices with the MatterSupport extension has become very unstable. Occasionally, the HomeUIService stops the flow after commissioning to the first fabric successfully, displaying the error: "Failed to perform Matter device setup: Error Domain=HMErrorDomain Code=2." (normally, it should send open commissioning window to the device and then add the device to the 2nd fabric). The issue is never seen before until recently few weeks and there is no code changes in the app. We are suspected that there is some data that fail to download from the icloud or apple account that cause this problem. For evaluation, we tried removing the HomeSupport extension and run the Matter framework directly in developer mode, this issue disappears, and commissioning works without any problems.

Hi all, We are migrating a SCSI HBA driver from KEXT to DriverKit (DEXT), with our DEXT inheriting from IOUserSCSIParallelInterfaceController. We've encountered a data corruption issue that is reliably reproducible under specific conditions and are hoping for some assistance from the community. Hardware and Driver Configuration: Controller: LSI 3108 DEXT Configuration: We are reporting our hardware limitations to the framework via the UserReportHBAConstraints function, with the following key settings: // UserReportHBAConstraints... addConstraint(kIOMaximumSegmentAddressableBitCountKey, 0x20); // 32-bit addConstraint(kIOMaximumSegmentCountWriteKey, 129); addConstraint(kIOMaximumByteCountWriteKey, 0x80000); // 512KB Observed Behavior: Direct I/O vs. Buffered I/O We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache: 1. Direct I/O (Bypassing System Cache) -> 100% Successful When we use fio with the direct=1 flag, our read/write and data verification tests pass perfectly for all file sizes, including 20GB+. 2. Buffered I/O (Using System Cache) -> 100% Failure at >128MB Whether we use the standard cp command or fio with the direct=1 option removed to simulate buffered I/O, we observe the exact same, clear failure threshold: Test Results: File sizes ≤ 128MB: Success. Data checksums match perfectly. File sizes ≥ 256MB: Failure. Checksums do not match, and the destination file is corrupted. Evidence of failure reproduced with fio (buffered_integrity_test.fio, with direct=1 removed): fio --size=128M buffered_integrity_test.fio -> Test Succeeded (err=0). fio --size=256M buffered_integrity_test.fio -> Test Failed (err=92), reporting the following error, which proves a data mismatch during the verification phase: verify: bad header ... at file ... offset 1048576, length 1048576 fio: ... error=Illegal byte sequence Our Analysis and Hypothesis The phenomenon of "Direct I/O succeeding while Buffered I/O fails" suggests the problem may be related to the cache synchronization mechanism at the end of the I/O process: Our UserProcessParallelTask_Impl function correctly handles READ and WRITE commands. When cp or fio (buffered) runs, the WRITE commands are successfully written to the LSI 3108 controller's onboard DRAM cache, and success is reported up the stack. At the end of the operation, to ensure data is flushed to disk, the macOS file system issues an fsync, which is ultimately translated into a SYNCHRONIZE CACHE SCSI command (Opcode 0x35 or 0x91) and sent to our UserProcessParallelTask_Impl. We hypothesize that our code may not be correctly identifying or handling this SYNCHRONIZE CACHE opcode. It might be reporting "success" up the stack without actually commanding the hardware to flush its cache to the physical disk. The OS receives this "success" status and assumes the operation is safely complete. In reality, however, the last batch of data remains only in the controller's volatile DRAM cache and is eventually lost. This results in an incomplete or incorrect file tail, and while the file size may be correct, the data checksum will inevitably fail. Summary Our DEXT driver performs correctly when handling Direct I/O but consistently fails with data corruption when handling Buffered I/O for files larger than 128MB. We can reliably reproduce this issue using fio with the direct=1 option removed. The root cause is very likely the improper handling of the SYNCHRONIZE CACHE command within our UserProcessParallelTask. P.S. This issue did not exist in the original KEXT version of the driver. We would appreciate any advice or guidance on this issue. Thank you.

I am developing a VoIP phone application(Our Phoneapp) using APNs VoIP push. I have a question regarding a behavior I discovered during testing of this application. When performing the following operations using an iPhoneSE3 with an sXGP-NW SIM inserted, 0xBAADCA11 occurs upon receiving an APNs VoIP PUSH. Do you have any information regarding this issue? 0xBAADCA11 occurs in operation 8. However, since there were no problems in operation 4 (the app works when Wi-Fi is off), I think there is no issue with the Our Phoneapp. [Configuration of system components] [VoIP Telephone] --Call to iPhone(Phoneapp)--> [Our VoIP PBX Server] -- VoIP PUSH request --> [Apple APNs Server] -- VoIP PUSH --> [Our Phoneapp (iPhoneSE3(with sXGP SIM)] [Operations] (The issue is reproducible 100% by following oparation) iPhoneSE3: Power on (iPhoneSE3 with sXGP SIM) iPhoneSE3: Wi-Fi off, connect to the internet via SIM. VoIP Telephone: Call to Our Phoneapp iPhoneSE3: Receives VoIP PUSH and Phoneapp launches. Successfully answers the call and communication is possible. (Receives VoIP push notification from APNs via sXGP SIM) iPhoneSE3: Wi-Fi is turned ON, connect to the internet via Wi-Fi. iPhoneSE3: Task kill Our Phoneapp. VoIP Telephone: Call to Our Phoneapp iPhoneSE3: iOS does not call the push notification delegate (didReceiveIncomingPushWithPayload). As a result our Phoneapp is unable to detect the incoming call, However, an ips log with 0xBAADCA11 is output. in other words, iOS received the VoIP PUSH, but Our Phoneapp dose not call CallKit, so Our Phoneapp was terminated by iOS.

Hi Folks, We are reading the USB device data from our app using libusb/iokit libraries. Before updating the MacOS to the 15.3 we never faced any issue but after updating OS to 15.3 Sequoia we started facing issue to access the USB device's information. We are not getting the device endpoints for the matching service and fails with below error- Error:Failed to create IOUSBHostObject. with reason: IOServiceOpen failed. Respective code snippet- service = IOServiceGetMatchingService(kIOMasterPortDefault, matchingDictionary); IOUSBHostInterface* interface = [[IOUSBHostInterface alloc] initWithIOService:service options:IOUSBHostObjectInitOptionsDeviceCapture queue:*queue error:&error interestHandler:nil]; We get the denial message during accessing the IOService error 23:17:30.691934-0800 kernel 41 duplicate reports for Sandbox: spotlightknowledged(1399) deny(1) mach-lookup com.apple.diagnosticd error 23:17:30.691945-0800 kernel System Policy: com.prograde.pgdrefreshpro.helpe(70515) deny(1) iokit-open-service IOUSBHostInterface Also when we checked the IOUSBHOST logs we can see pipes are stalled while running the RefreshPro app as below- 2025-02-05 22:06:31.838141-0800 0x25913e Error 0x0 0 0 kernel: (IOUSBHostFamily) AppleUSBIORequest: AppleUSBIORequest::complete: device 8 (SD PG05.5@08210000) endpoint 0x00: status 0xe0005000 (pipe stalled): 0 bytes transferred We need an assistance here to know what exactly could be the cause and how can we elevate the permissions to access the USB device on MacOS15.3. Do we need other entitlements? As we never faced such issue with our certificate and Identifier on any MacOS versions and with the current entitlements we have. Do we need to include any entitlement in the code? Thanks.

Description The Shortcut Automation Trigger Transaction frequently times out, ultimately causing the shortcut automation to fail. Please see the attached trace for details. Additionally, the Trigger is activated even when the Transaction is declined. Details In the trace I see the error: [WFWalletTransactionProvider observeForUpdatesWithInitialTransactionIfNeeded:transactionIdentifier:completion:]_block_invoke Hit timeout waiting for transaction with identifier: <private>, finishing. Open bug report: FB14035016

I have published the app on the App Store along with its corresponding app clip, my app clip is configured with some advanced experiences for each one of my clients, but whenever some users try to scan an NFC or QR Code they see the card rendering correctly with their configured banner image, but with the message "App Clip Unavailable". The weird thing is that both iMessage and the website to which the associated domain is set and the apple-app-site-association is stored, renders the banner or card correctly, and when the users tap the banner or card they open the advanced app clip experience correctly without any issue. I have attempted to troubleshoot the issue by checking the following: if the app clip is below 15MB if we are using a second level domain in my associated domain both for my app clip and app (excluding the www subdomain). checking if the AASA is correctly stored inside .well-known directory checking the configuration for the advanced experience I opened a case: 102233443873, and added a bunch of videos and screenshot showcasing the issue, but I have not yet received a reply

I have an iOS app with ExtensionFoundation. It runs well on my local device, but when I upload on the AppStore it gets rejected with: Validation failed Invalid Info.plist value. The value of the EXExtensionPointIdentifier key, AsheKube.app.a-Shell.localWebServer, in the Info.plist of “a-Shell.app/Extensions/localWebServer.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: ae8dd1dd-8caf-4a48-9651-7a225faed4eb) The Info.plist in my Extension is: <?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>EXAppExtensionAttributes</key> <dict> <key>EXExtensionPointIdentifier</key> <string>com.example.example-extension</string> </dict> </dict> </plist> so the Info.plist that causes the issue has been automatically generated by Xcode. I can access it as well, and it says: { "BuildMachineOSBuild" => "25A354" "CFBundleDevelopmentRegion" => "en" "CFBundleDisplayName" => "localWebServerExtension" "CFBundleExecutable" => "localWebServer" "CFBundleIdentifier" => "AsheKube.app.a-Shell.localWebServerExtension" "CFBundleInfoDictionaryVersion" => "6.0" "CFBundleName" => "localWebServer" "CFBundlePackageType" => "XPC!" "CFBundleShortVersionString" => "1.0" "CFBundleSupportedPlatforms" => [ 0 => "iPhoneOS" ] "CFBundleVersion" => "1" "DTCompiler" => "com.apple.compilers.llvm.clang.1_0" "DTPlatformBuild" => "23A339" "DTPlatformName" => "iphoneos" "DTPlatformVersion" => "26.0" "DTSDKBuild" => "23A339" "DTSDKName" => "iphoneos26.0" "DTXcode" => "2601" "DTXcodeBuild" => "17A400" "EXAppExtensionAttributes" => { "EXExtensionPointIdentifier" => "AsheKube.app.a-Shell.localWebServer" } "MinimumOSVersion" => "26.0" "NSHumanReadableCopyright" => "Copyright © 2025 AsheKube. All rights reserved." "UIDeviceFamily" => [ 0 => 1 1 => 2 ] "UIRequiredDeviceCapabilities" => [ 0 => "arm64" ] } What should I do to be able to upload on the AppStore?

I just released an App update the didn't touch ANYTHING to do with Core Data (nothing changed in our Coredata code for at least 8 months). The update uses SDK for iOS 18 and Xcode 16.2 and the app now requires iOS 18 and was a minor bug patch and UI improvements for recent iOS changes. Since the update we are getting a steady trickle of users on iOS 18, some who allow the App to store data in iCloud (Cloudkit) and others who do not, all reporting that after the update to our recent release ALL their data is gone?! I had not seen this on ANY device until today when I asked a friend who uses the App if they had the issue and it turned out they did, so I hooked their device up to Xcode and ALL the data in the CoreData database was gone?! They are NOT using iCloud. There were no errors or exceptions on Xcode console but a below code returned NO records at all?! Chart is custom entity and is defined as: @interface Chart : NSManagedObject {} let moc = pc.viewContext let chartsFetch = NSFetchRequest<NSFetchRequestResult>(entityName:"Charts") // Fetch all Charts do { let fetchedCharts = try moc.fetch(chartsFetch) as! [Chart] for chart in fetchedCharts { .... } } A break point inside the do on fetchedCharts show there are NO objects returned. This is a serious issue and seems like an iOS 18 thing. I saw some people talking in here about NSFetchRequest issues with iOS 18. I need some guidance here from someone Apple engineer here who knows what the status of these NSFetchrequest bugs are and what possible workarounds are. Becasue this problem will grow for me as more users update to iOS 18.

I am writing an app using Microsoft's MAUI platform. I am posting this here because that team wants me to make an xcode project to help determine an issue I am having. My MAUI app sends a broadcast packet on a UDP socket using address 255.255.255.255. This worked fine in iOS version 17.x. After upgrading my phone to iOS 18.x it stopped working. The error I get is "no route to host". The exact same code works fine on MacOS. It does not work on iPadOs 18. My question here is 3 fold: Did something specific change between iOS 17 and 18 that would cause a 'no route to host' error when sending a UDP broadcast packet? Can someone provide sample code to show me how to do this type of broadcast using Swift in Xcode for iOS? I read an article that said my app would need the com.apple.developer.networking.multicast entitlement in order to use boradcast functionality. This was introduced in iOS 14. Why did my app work fine in iOS 17 then? Is this what changed? Did this requirement use to be optional and is now required? I did get this entitlement from Apple and applied it to my provisioning profile and my app gave the same "no route to host" error. Why?

I can develop a PacketTunnelProvider on Mac with xcode. I work with my self codesign. But when I sign it with Developer ID after read https://developer.apple.com/forums/thread/737894 , it still fail when I turn on the vpn .

Hello everyone, We are migrating our KEXT for a Thunderbolt storage device to a DEXT based on IOUserSCSIParallelInterfaceController. We've run into a fundamental issue where the driver's behavior splits based on the I/O source: high-level I/O from the file system (e.g., Finder, cp) is mostly functional (with a minor ls -al sorting issue for Traditional Chinese filenames), while low-level I/O directly to the block device (e.g., diskutil) fails or acts unreliably. Basic read/write with dd appears to be mostly functional. We suspect that our DEXT is failing to correctly register its full device "personality" with the I/O Kit framework, unlike its KEXT counterpart. As a result, low-level I/O requests with special attributes (like cache synchronization) sent by diskutil are not being handled correctly by the IOUserSCSIParallelInterfaceController framework of our DEXT. Actions Performed & Relevant Logs 1. Discrepancy: diskutil info Shows Different Device Identities for DEXT vs. KEXT For the exact same hardware, the KEXT and DEXT are identified by the system as two different protocols. KEXT Environment: Device Identifier: disk5 Protocol: Fibre Channel Interface ... Disk Size: 66.0 TB Device Block Size: 512 Bytes DEXT Environment: Device Identifier: disk5 Protocol: SCSI SCSI Domain ID: 2 SCSI Target ID: 0 ... Disk Size: 66.0 TB Device Block Size: 512 Bytes 2. Divergent I/O Behavior: Partial Success with Finder/cp vs. Failure with diskutil High-Level I/O (Partially Successful): In the DEXT environment, if we operate on an existing volume (e.g., /Volumes/MyVolume), file copy operations using Finder or cp succeed. Furthermore, the logs we've placed in our single I/O entry point, UserProcessParallelTask_Impl, are triggered. Side Effect: However, running ls -al on such a volume shows an incorrect sorting order for files with Traditional Chinese names (they appear before . and ..). Low-Level I/O (Contradictory Behavior): In the DEXT environment, when we operate directly on the raw block device (/dev/disk5): diskutil partitionDisk ... -> Fails 100% of the time with the error: Error: -69825: Wiping volume data to prevent future accidental probing failed. dd command -> Basic read/write operations appear to work correctly (a write can be immediately followed by a read within the same DEXT session, and the data is correct). 3. Evidence of Cache Synchronization Failure (Non-deterministic Behavior) The success of the dd command is not deterministic. Cross-environment tests prove that its write operations are unreliable: First Test: In the DEXT environment, write a file with random data to /dev/disk5 using dd. Reboot into the KEXT environment. Read the data back from /dev/disk5 using dd. The result is a file filled with all zeros. Conclusion: The write operation only went to the hardware cache, and the data was lost upon reboot. Second Test: In the DEXT environment, write the same random file to /dev/disk5 using dd. Key Variable: Immediately after, still within the DEXT environment, read the data back once for verification. The content is correct! Reboot into the KEXT environment. Read the data back from /dev/disk5. This time, the content is correct! Conclusion: The additional read operation in the second test unintentionally triggered a hardware cache flush. This proves that the dd (in our DEXT) write operation by itself does not guarantee synchronization, making its behavior unreliable. Our Problem Based on the observations above, we have the conclusion: High-Level Path (triggered by Finder/cp): When an I/O request originates from the high-level file system, the framework seems to enter a fully-featured mode. In this mode, all SCSI commands, including READ/WRITE, INQUIRY, and SYNCHRONIZE CACHE, are correctly packaged and dispatched to our UserProcessParallelTask_Impl entry point. Therefore, Finder operations are mostly functional. Low-Level Path (triggered by dd/diskutil): When an I/O request originates from the low-level raw block device layer: The most basic READ/WRITE commands can be dispatched (which is why dd appears to work). However, critical management commands, such as INQUIRY and SYNCHRONIZE CACHE, are not being correctly dispatched or handled. This leads to the incorrect device identification in diskutil info and the failure of diskutil partitionDisk due to its inability to confirm cache synchronization. We would greatly appreciate any guidance, suggestions, or insights on how to resolve this discrepancy. Specifically, what is the recommended approach within DriverKit to ensure that a DEXT based on IOUserSCSIParallelInterfaceController can properly declare its capabilities and handle both high-level and low-level I/O requests uniformly? Thank you. Charles