Hi, I’m implementing a macOS DNS Proxy as a system extension and running into a persistent activation error: OSSystemExtensionErrorDomain error 9 (validationFailed) with the message: extension category returned error This happens both on an MDM‑managed Mac and on a completely clean Mac (no MDM, fresh install). Setup macOS: 15.x (clean machine, no MDM) Xcode: 16.x Team ID: AAAAAAA111 (test) Host app bundle ID: com.example.agent.NetShieldProxy DNS Proxy system extension bundle ID: com.example.agent.NetShieldProxy.dnsProxy The DNS Proxy is implemented as a NetworkExtension system extension, not an app extension. Host app entitlements From codesign -d --entitlements :- /Applications/NetShieldProxy.app: xml com.apple.application-identifier AAAAAAA111.com.example.agent.NetShieldProxy <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.team-identifier</key> <string>AAAAAAA111</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.NetShieldmac</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> xml com.apple.application-identifier AAAAAAA111.com.example.agent.NetShieldProxy.dnsProxy <key>com.apple.developer.networking.networkextension</key> <array> <string>dns-proxy-systemextension</string> </array> <key>com.apple.developer.team-identifier</key> <string>AAAAAAA111</string> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.NetShieldmac</string> <string>group.example.NetShieldmac</string> <string>group.example.agent.enterprise.macos</string> <string>group.example.com.NetShieldmac</string> </array> DNS Proxy system extension Info.plist On the clean Mac, from: bash plutil -p "/Applications/NetShieldProxy.app/Contents/Library/SystemExtensions/com.example.agent.NetShieldProxy.dnsProxy.systemextension/Contents/Info.plist" I get: json { "CFBundleExecutable" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundleIdentifier" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundleName" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundlePackageType" => "SYSX", "CFBundleShortVersionString" => "1.0.1.8", "CFBundleSupportedPlatforms" => [ "MacOSX" ], "CFBundleVersion" => "0.1.1", "LSMinimumSystemVersion" => "13.5", "NSExtension" => { "NSExtensionPointIdentifier" => "com.apple.dns-proxy", "NSExtensionPrincipalClass" => "com_example_agent_NetShieldProxy_dnsProxy.DNSProxyProvider" }, "NSSystemExtensionUsageDescription" => "SYSTEM_EXTENSION_USAGE_DESCRIPTION" } The DNSProxyProvider class inherits from NEDNSProxyProvider and is built in the system extension target. Activation code In the host app, I use: swift import SystemExtensions final class SystemExtensionActivator: NSObject, OSSystemExtensionRequestDelegate { private let extensionIdentifier = "com.example.agent.NetShieldProxy.dnsProxy" func activate(completion: @escaping (Bool) -> Void) { let request = OSSystemExtensionRequest.activationRequest( forExtensionWithIdentifier: extensionIdentifier, queue: .main ) request.delegate = self OSSystemExtensionManager.shared.submitRequest(request) } func request(_ request: OSSystemExtensionRequest, didFailWithError error: Error) { let nsError = error as NSError print("Activation failed:", nsError) } func request(_ request: OSSystemExtensionRequest, didFinishWithResult result: OSSystemExtensionRequest.Result) { print("Result:", result.rawValue) } } Runtime behavior on a clean Mac (no MDM) config.plist is created under /Library/Application Support/NetShield (via a root shell script). A daemon runs, contacts our backend, and writes /Library/Application Support/NetShield/state.plist with a valid dnsToken and other fields. The app NetShieldProxy.app is installed via a notarized, stapled Developer ID .pkg. The extension bundle is present at: /Applications/NetShieldProxy.app/Contents/Library/SystemExtensions/com.example.agent.NetShieldProxy.dnsProxy.systemextension. When I press Activate DNS Proxy in the UI, I see in the unified log: text NetShieldProxy: [com.example.agent:SystemExtensionActivator] Requesting activation for system extension: com.example.agent.NetShieldProxy.dnsProxy NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - activation failed: extension category returned error (domain=OSSystemExtensionErrorDomain code=9) NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - OSSystemExtensionError code enum: 9 NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - validationFailed And: bash systemextensionsctl list -> 0 extension(s) There is no prompt in Privacy & Security on this clean Mac. Question Given: The extension is packaged as a system extension (CFBundlePackageType = SYSX) with NSExtensionPointIdentifier = "com.apple.dns-proxy". Host and extension share the same Team ID and Developer ID Application cert. Entitlements on the target machine match the provisioning profile and Apple’s docs for DNS Proxy system extensions (dns-proxy-systemextension). This is happening on a clean Mac with no MDM profiles at all. What are the likely reasons for OSSystemExtensionErrorDomain error 9 (validationFailed) with "extension category returned error" in this DNS Proxy system extension scenario? Is there any additional configuration required for DNS Proxy system extensions (beyond entitlements and Info.plist) that could trigger this category-level validation failure? Any guidance or examples of a working DNS Proxy system extension configuration (host entitlements + extension Info.plist + entitlements) would be greatly appreciated. Thanks!

What is the best way to detect if the Wifi is being used for Wireless Carplay or is just a normal network interface?

I have been using the SCNetworkReachabilityGetFlags for 10+ years to inform users that their request won't work. In my experience this works pretty well although i am aware of the limitations. Now, i am looking into the NWPathMonitor, and i have one situation that i'm trying to. get my head around - it's asynchronous. Specifically, i am wondering what to do when my geofences trigger and i want to check network connectivity - i want to tell the user why the operation i'll perform because of the trigger couldn't be done. SO. say i start a NWPathMonitor in didFinishLaunchingWithOptions. When the app is booted up because of a geofence trigger, might i not end up in a case where my didEnterRegion / didExitRegion gets called before the NWPathMonitor has gotten its first status? The advantage here with SCNetworkReachabilityGetFlags, as i understand it, would be that it's synchronous? If i want to upgrade to nwpathmonitor, i guess i have to do a method that creates a nwpathmonitor, uses a semaphore to wait for the first callback, then contunues? Thoughts appreciated

I've spent a few months writing an app that uses SwiftData with inheritance. Everything worked well until I tried adding CloudKit support. To do so, I had to make all relationships optional, which exposed what appears to be a bug. Note that this isn't a CloudKit issue -- it happens even when CloudKit is disabled -- but it's due to the requirement for optional relationships. In the code below, I get the following error on the second call to modelContext.save() when the button is clicked: Could not cast value of type 'SwiftData.PersistentIdentifier' (0x1ef510b68) to 'SimplePersistenceIdentifierTest.Computer' (0x1025884e0). I was surprised to find zero hit when Googling "Could not cast value of type 'SwiftData.PersistentIdentifier'". Some things to note: Calling teacher.computers?.append(computer) instead of computer.teacher = teacher results in the same error. It only happens when Teacher inherits Person. It only happens if modelContext.save() is called both times. It works if the first modelContext.save() is commented out. If the second modelContext.save()is commented out, the error occurs the second time the model context is saved (whether explicitly or implicitly). Keep in mind this is a super simple repro written to generate on demand the error I'm seeing in a normal app. In my app, modelContext.save() must be called in some places to update the UI immediately, sometimes resulting in the error seconds later when the model context is saved automatically. Not calling modelContext.save() doesn't appear to be an option. To be sure, I'm new to this ecosystem so I'd be thrilled if I've missed something obvious! Any thoughts are appreciated. import Foundation import SwiftData import SwiftUI struct ContentView: View { @Environment(\.modelContext) var modelContext var body: some View { VStack { Button("Do it") { let teacher = Teacher() let computer = Computer() modelContext.insert(teacher) modelContext.insert(computer) try! modelContext.save() computer.teacher = teacher try! modelContext.save() } } } } @Model class Computer { @Relationship(deleteRule: .nullify) var teacher: Teacher? init() {} } @Model class Person { init() {} } @available(iOS 26.0, macOS 26.0, *) @Model class Teacher: Person { @Relationship(deleteRule: .nullify, inverse: \Computer.teacher) public var computers: [Computer]? = [] override init() { super.init() } }

Based on https://developer.apple.com/documentation/networkextension/nednssettings/searchdomains , we expect the values mentioned in searchDomains to be appended to a single label DNS query. However, we are not seeing this behavior. We have a packetTunnelProvider VPN, where we set searchDomains to a dns suffix (for ex: test.com) and we set matchDomains to applications and suffix (for ex: abc.com and test.com) . When a user tries to access https://myapp , we expect to see a DNS query packet for myapp.test.com . However, this is not happening when matchDomainsNoSearch is set to true. https://developer.apple.com/documentation/networkextension/nednssettings/matchdomainsnosearch When matchDomainsNoSearch is set to false, we see dns queries for myapp.test.com and myapp.abc.com. What is the expected behavior of searchDomains?

Since upgrading to Mac OS 10.5 Beta-2, daemons launched with launchctl are failing to open Desktop/Documents/Downloads files and folders even in read mode with an error "Operation not permitted".Does anyone facing this issue?

After pairing and having subscribed to a service, and even after having exchanged messages, the service fails after a period of time and both devices need to pair again.

Hi, I am currently experiencing some trouble when using parent model property in a predicate of a child model. I have an Item class that define parent-child relationship: @Model class Item { var timestamp: Date @Relationship(inverse: \Item.children) var parent: Item? var children: [Item] init(parent: Item? = nil, children: [Item] = [], timestamp: Date = .now) { self.parent = parent self.children = children self.timestamp = timestamp } } I subclass this model like that: @available(iOS 26, *) @Model final class CollectionItem: Item { /* ... */ } When i make a Query in my View like that the system crashes: @Query( filter: #Predicate<CollectionItem> { $0.parent == nil }, sort: \CollectionItem.name, ) private var collections: [CollectionItem] CrashReportError: Fatal Error in DataUtilities.swift AppName crashed due to fatalError in DataUtilities.swift at line 85. Couldn't find \CollectionItem.<computed 0x000000034005d4e8 (Optional<Item>)> on CollectionItem with fields [SwiftData.Schema.PropertyMetadata(name: "name", keypath: \CollectionItem.<computed 0x000000034003c120 (String)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "icon", keypath: \CollectionItem.<computed 0x000000034003ca04 (Optional<String>)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "timestamp", keypath: \Item.<computed 0x0000000340048018 (Date)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "parent", keypath: \Item.<computed 0x0000000340048a4c (Optional<Item>)>, defaultValue: nil, metadata: Optional(Relationship - name: , options: [], valueType: Any, destination: , inverseName: nil, inverseKeypath: Optional(\Item.<computed 0x0000000340048fe8 (Array<Item>)>))), SwiftData.Schema.PropertyMetadata(name: "children", keypath: \Item.<computed 0x0000000340048fe8 (Array<Item>)>, defaultValue: nil, metadata: nil)] When I query as Item it works but then i cannot sort on CollectionItem field and must add unnecessary down casting: @Query( filter: #Predicate<Item> { $0.parent == nil && $0 is CollectionItem }, ) private var items: [Item] Am I missing something? Is it a platform limitation or a known issue?

Continuing with my investigations of several issues that we have been noticing in our testing of the JDK with macosx 15.x, I have now narrowed down at least 2 separate problems for which I need help. For a quick background, starting with macosx 15.x several networking related tests within the JDK have started failing in very odd and hard to debug ways in our internal lab. Reading through the macos docs and with help from others in these forums, I have come to understand that a lot of these failures are to do with the new restrictions that have been placed for "Local Network" operations. I have read through https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy and I think I understand the necessary background about these restrictions. There's more than one issue in this area that I will need help with, so I'll split them out into separate topics in this forum. That above doc states: macOS 15.1 fixed a number of local network privacy bugs. If you encounter local network privacy problems on macOS 15.0, retest on macOS 15.1 or later. We did have (and continue to have) 15.0 and 15.1 macos instances within our lab which are impacted by these changes. They too show several networking related failures. However, I have decided not to look into those systems and instead focus only on 15.3.1. People might see unexpected behavior in System Settings > Privacy & Security if they have multiple versions of the same app installed (FB15568200). This feedback assistant issue and several others linked in these documentations are inaccessible (even when I login with my existing account). I think it would be good to have some facility in the feedback assistant tool/site to make such issues visible (even if read-only) to be able to watch for updates to those issues. So now coming to the issue. Several of the networking tests in the JDK do mulicasting testing (through BSD sockets API) in order to test the Java SE multicasting socket API implementations. One repeated failure we have been seeing in our labs is an exception with the message "No route to host". It shows up as: Process id: 58700 ... java.net.NoRouteToHostException: No route to host at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method) at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:914) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:871) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:798) at java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:857) at java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:178) at java.base/java.net.DatagramSocket.send(DatagramSocket.java:593) (this is just one example stacktrace from java program) That "send0" is implemented by the JDK by invoking the sendto() system call. In this case, the sendto() is returning a EHOSTUNREACH error which is what is then propagated to the application. The forum text editor doesn't allow me to post long text, so I'm going to post the rest of this investigation and logs as a reply.

Our app is developed for iOS, but some users also run it on macOS (as an iOS app via Apple Silicon). The app requires local network permission, which works perfectly on iOS. Previously, the connection also worked fine on macOS, but since the recent macOS update, the app can no longer connect to our device. Additionally, our app on macOS doesn't prompt for local network permission at all, whereas it does on iOS. Is this a known issue with iOS apps running on macOS? Has anyone else experienced this problem, or is there a workaround? Any help would be appreciated!

I am using SwiftData for storage and have a view that uses the @Query property wrapper with a sort descriptor that points to a relationship on a model. In a release build on device running iOS 18.3, the app crashes. This is the line that crashes: @Query(sort: \Item.info.endDate, order: .reverse) private var items: [Item] Item has a relationship to ItemInfo, which is where the endDate property is defined. This code works in debug and on a simulator. In the project referenced here: https://github.com/lepolt/swiftdata-crash, change the scheme build configuration to “Release” and run on device. The app will crash. Using Xcode Version 16.2 (16C5032a) iPhone 12, iOS 18.3 (22D60)

Hello, We're developing endpoint security software using the Endpoint Security framework, and we've encountered challenges with the behavior change in macOS 15 regarding provisioning UDIDs in cloned VMs. The Change Prior to macOS 15, cloning a VM preserved its UDID (format: 0000FE00-9C4ED9F68BBDC72D). Starting with macOS 15, cloned VMs receive a new UDID generated from the host's Secure Enclave (format: b043d27202c7ac37ca3c6b82673302225485cae9), making each clone effectively a new device. Our Workflow We maintain a clean base VM image and clone it for each test run. We add the base VM's UDID to our provisioning profile once, then create clones which (previously) retained that same UDID, allowing us to start new testing cycles without re-registering devices. This is essential because our product involves low-level system integration through the Endpoint Security framework, and if something goes wrong during development, it has the potential to affect system stability. To prevent any cascading issues between test runs or different product versions, we need each test to start from a known clean state rather than reusing the same VM. The Challenge With each VM clone generating a new UDID, we're hitting Apple's device registration limits quickly. This particularly impacts: New team members who spin up VMs for the first time and can't run signed builds Our CI/CD pipeline where multiple test environments need provisioning profiles Developers testing different branches who need separate clean environments Current Workaround We've found that VMs created on macOS 14 and upgraded to macOS 15+ retain their original UDID format. However, we're concerned this workaround may stop working in future macOS versions, which would leave us without a viable path forward. If the workaround stops working, our fallback would be signing each CI build with a Developer ID signature to allow running on any device. However, we'd prefer to avoid this as it would significantly increase load on Apple's signing infrastructure for what are essentially internal test builds. We completely understand the security reasoning behind tying UDIDs to the host's Secure Enclave for Apple Account support. However, for development workflows that don't require Apple Account features in VMs but do require clean, isolated test environments, the previous behavior was quite valuable. Question Is there a recommended approach for teams in our situation? We're happy to explore alternative workflows if there's a pattern we're missing, or we'd be glad to provide more context if this is a use case Apple is considering for future updates. Thanks for any guidance you can provide! Feedback case: FB21389730

We are experiencing a large number of crashes in our production environment, mainly occurring on iOS 16 systems and iPhone 8 and iPhone X devices. The crash log and stack trace are as follows: Error: Assertion failed: (false) function _onqueue_rdar53306264_addWaiter file TubeManager.cpp line 1042 Crashed: com.apple.CFNetwork.LoaderQ 0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8 1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208 2 libsystem_c.dylib 0x1c4b8 abort + 124 3 libsystem_c.dylib 0x70d8c err + 266 4 CFNetwork 0x1eb80 CFURLRequestSetMainDocumentURL + 6288 5 CFNetwork 0x44fd8 CFURLCacheRemoveAllCachedResponses + 22624 6 CFNetwork 0x39460 _CFHostIsDomainTopLevel + 968 7 CFNetwork 0x1f754 CFURLRequestSetMainDocumentURL + 9316 8 CFNetwork 0x233e0 CFURLRequestSetRequestPriority + 8792 9 CFNetwork 0x20d38 CFURLRequestCopyHTTPRequestBodyStream + 1612 10 CFNetwork 0x4f950 CFHTTPCookieStorageCopyCookies + 16276 11 CFNetwork 0x15878 CFURLRequestSetURL + 7600 12 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24 13 libdispatch.dylib 0x64780 _dispatch_client_callout + 16 14 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600 15 libdispatch.dylib 0x401e4 _dispatch_lane_invoke$VARIANT$armv81 + 432 16 libdispatch.dylib 0x41304 _dispatch_workloop_invoke$VARIANT$armv81 + 1620 17 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608 18 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284 19 libsystem_pthread.dylib 0x1720 start_wqthread + 8 Have you encountered a similar issue before?

The documentation for CGColorRef (https://developer.apple.com/documentation/coregraphics/cgcolorref?language=objc) clearly shows that it is a struct. However, when I try to store a cell's border color using CGColorRef originalColor = self.bg.layer.borderColor and inspect what happens in the debugger, both that property and its copy have the same address. And later when I try to restore the border color the copy still has the same address but is no longer valid and causes a crash on assignment (originalColor is actually an instance variable...) This is all object behavior, not struct behavior. If CGColorRef really was a struct, the contents would have been copied, the instance variable would have had its own address that would never have changed, and the value would have remained valid indefinitely and let me copy it back without a problem. Why is this documented wrong? Was this a recent change? I actually had this code working at some point, and now it's broken.

I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁. What current and past iPhone and iPad models support Wi-Fi Aware? And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?

Hello I've noticed that this product, heavily promoted on the ASC forums for many years, is no longer available from the Apple App Store. Can anyone tell me the reason why the product is no longer supported? Friends have asked me if it is 'safe' to use. Is it? Note to moderator: If I'm asking in the wrong places, please redirect my question. Thank you.

Hello, When an iOS app runs on Vision Pro in compatible mode, is there a flag such as isiOSAppOnVision to determine the underlying OS at runtime? Just like the ProcessInfo.isiOSAppOnMac. It will be useful to optimize the app for visionOS. Already checked but not useful: #if os(xrOS) does not work in compatible mode since no code is recompiled. UIDevice.userInterfaceIdiom returns .pad instead of .reality. Thanks.

I've been trying to add a CoreSpotlight indexer to my macOS application. The new template for the indexer uses the new appex CSImportExtension style importer. I've been following this -> https://developer.apple.com/documentation/corespotlight/csimportextension I changed the CSSupportedContentTypes in the Info.plist file to the correct file type uti. I added a dummy value into the attributes (see code below) - just setting contentDescription to 'noodle' (easy to search for) class ImportExtension: CSImportExtension {   override func update(_ attributes: CSSearchableItemAttributeSet, forFileAt: URL) throws {     // Add a dummy value, and see whether spotlight finds it     attributes.contentDescription = "noodle" } } I have a number of files on disk that match the uti (and can be found when I search by the file name) Yet, when I build and run my app, the a spotlight search for 'noodle' finds no results. Can anyone give me any advice? I cannot find any indication that the ImportExtension is called (although when I put a log message at the start of the update() call there's no message in the console which seems to suggest it's not being called). Is there any way of debugging this? Cheers and thanks -- Darren.

I have a strange crash which I have problems understanding. It only happens on a few devices, after a ModelContainer migration, and it doesn't seem to crash on the migration itself. The fetch is done in onAppear, and shouldn't necessarily result in a crash, as it is an optional try: let request = FetchDescriptor<Rifle>() let data = try? modelContext.fetch(request) if let data, !data.isEmpty { rifle = data.first(where: { $0.uuid.uuidString == settings.selectedRifleId }) ?? data.first! } When I get logs from users, there seems to be an error in encoding? Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000018e8bfd78 Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [71687] Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libswiftCore.dylib 0x18e8bfd78 _assertionFailure(_:_:file:line:flags:) + 264 1 SwiftData 0x24e18b480 0x24e14c000 + 259200 2 SwiftData 0x24e193968 0x24e14c000 + 293224 3 SwiftData 0x24e195a78 0x24e14c000 + 301688 4 libswiftCore.dylib 0x18e8e4084 _KeyedEncodingContainerBox.encodeNil<A>(forKey:) + 352 5 libswiftCore.dylib 0x18e8d79f0 KeyedEncodingContainer.encodeNil(forKey:) + 64 6 SwiftData 0x24e19f09c 0x24e14c000 + 340124 7 SwiftData 0x24e1a3dec 0x24e14c000 + 359916 8 libswiftCore.dylib 0x18ec10be8 dispatch thunk of Encodable.encode(to:) + 32 9 SwiftData 0x24e1cd500 0x24e14c000 + 529664 10 SwiftData 0x24e1cd0c8 0x24e14c000 + 528584 11 SwiftData 0x24e1da960 0x24e14c000 + 584032 12 SwiftData 0x24e1ee2ec 0x24e14c000 + 664300 13 SwiftData 0x24e1d97d8 0x24e14c000 + 579544 14 SwiftData 0x24e1eada0 0x24e14c000 + 650656 15 SwiftData 0x24e1d989c 0x24e14c000 + 579740 16 SwiftData 0x24e1eee78 0x24e14c000 + 667256 17 Impact 0x1027403bc 0x10268c000 + 738236

MacOS(Apple Silicon) IOKit driver for FPGA DMA transmission, kernel panic. Hardware and software configuration: MAC mini M1 2020 16GB, macOS Ventura 13.0 or 13.7.8 FPGA device capability: 64-bit Complete description: We've developed a DMA driver for PCIe devices (FPGA) based on IOKit. The driver can start normally through kextload, and the bar mapping, DMA registers, etc. are all correct. I am testing DMA data transmission, but a kernel panic has occurred. The specific content of the panic is as follows: {"bug_type":"210","timestamp":"2026-01-28 14:35:30.00 +0800","os_version":"macOS 13.0 (22A380)","roots_installed":0,"incident_id":"61C9B820-8D1B-4E75-A4EB-10DC2558FA75"} { "build" : "macOS 13.0 (22A380)", "product" : "Macmini9,1", "socId" : "0x00008103", "kernel" : "Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103", "incident" : "61C9B820-8D1B-4E75-A4EB-10DC2558FA75", "crashReporterKey" : "6435F6BD-4138-412A-5142-83DD7E5B4F61", "date" : "2026-01-28 14:35:30.16 +0800", "panicString" : "panic(cpu 0 caller 0xfffffe0026c78c2c): "apciec[pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x02220060 linkcdmsts=0x00000000 (ltssm 0x11=L0)\n" @AppleT8103PCIeCPort.cpp:1301\nDebugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 22A380\nKernel version: Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103\nFileset Kernelcache UUID: C222B4132B9708E5E0E2E8B8C5896410\nKernel UUID: 0BFE6A5D-118B-3889-AE2B-D34A0117A062\nBoot session UUID: 61C9B820-8D1B-4E75-A4EB-10DC2558FA75\niBoot version: iBoot-8419.41.10\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x000000001d1b4000\nKernelCache base: 0xfffffe00241b8000\nKernel slide: 0x000000001e3f8000\nKernel text base: 0xfffffe00253fc000\nKernel text exec slide: 0x000000001e4e0000\nKernel text exec base: 0xfffffe00254e4000\nmach_absolute_time: 0x907c3082\nEpoch Time: sec usec\n Boot : 0x6979adbb 0x00023a6a\n Sleep : 0x00000000 0x00000000\n Wake : 0x00000000 0x00000000\n Calendar: 0x6979ae1a 0x00064953\n\nZone info:\n Zone map: 0xfffffe1000834000 - 0xfffffe3000834000\n . VM : 0xfffffe1000834000 - 0xfffffe14cd500000\n . RO : 0xfffffe14cd500000 - 0xfffffe1666e98000\n . GEN0 : 0xfffffe1666e98000 - 0xfffffe1b33b64000\n . GEN1 : 0xfffffe1b33b64000 - 0xfffffe2000830000\n . GEN2 : 0xfffffe2000830000 - 0xfffffe24cd4fc000\n . GEN3 : 0xfffffe24cd4fc000 - 0xfffffe299a1c8000\n . DATA : 0xfffffe299a1c8000 - 0xfffffe3000834000\n Metadata: 0xfffffe3f4d1ac000 - 0xfffffe3f551ac000\n Bitmaps : 0xfffffe3f551ac000 - 0xfffffe3f5ac94000\n\nCORE 0 recently retired instr at 0xfffffe002569d7a0\nCORE 1 recently retired instr at 0xfffffe002569eea0\nCORE 2 recently retired instr at 0xfffffe002569eea0\nCORE 3 recently retired instr at 0xfffffe002569eea0\nCORE 4 recently retired instr at 0xfffffe002569eea0\nCORE 5 recently retired instr at 0xfffffe002569eea0\nCORE 6 recently retired instr at 0xfffffe002569eea0\nCORE 7 recently retired instr at 0xfffffe002569eea0\nTPIDRx_ELy = {1: 0xfffffe2000c23010 0: 0x0000000000000000 0ro: 0x0000000000000000 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 3 PVH locks held: None\nCORE 4 PVH locks held: None\nCORE 5 PVH locks held: None\nCORE 6 PVH locks held: None\nCORE 7 PVH locks held: None\nCORE 0 is the one that panicked. Check the full backtrace for details.\nCORE 1: PC=0xfffffe00279db94c, LR=0xfffffe00260d5d9c, FP=0xfffffe8ffecaf850\nCORE 2: PC=0xfffffe0025be76b0, LR=0xfffffe0025be7628, FP=0xfffffe8fff08f5f0\nCORE 3: PC=0x00000001c7cacd78, LR=0x00000001c7cacd84, FP=0x000000016f485130\nCORE 4: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffe1dff00\nCORE 5: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff5eff00\nCORE 6: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffed8bf00\nCORE 7: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff11bf00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe1b33aad678: 0 pages, 470 threads: pid 0: kernel_task\nPanicked thread: 0xfffffe2000c23010, backtrace: 0xfffffe8fff6eb6a0, tid: 265\n\t\t ... Kernel Extensions in backtrace:\n com.apple.driver.AppleT8103PCIeC(1.0)[A595D104-026A-39E5-93AA-4C87CE8C14D2]@0xfffffe0026c619d0->0xfffffe0026c86c97\n dependency: com.apple.driver.AppleARMPlatform(1.0.2)[11A9713E-6739-3A4C-8571-2D8EAA062278]@0xfffffe0025f13ff0->0xfffffe0025f6255f\n dependency: com.apple.driver.AppleEmbeddedPCIE(1)[E71CBCCD-AEB8-3E7B-933D-4FED4241BF13]@0xfffffe002654e0b0->0xfffffe00265684c7\n dependency: com.apple.driver.ApplePIODMA(1)[A419BABC-A7A3-316D-A150-7C2C2D1F6D53]@0xfffffe00269a24b0->0xfffffe00269a6c3b\n dependency: com.apple.driver.IODARTFamily(1)[03997E20-8A3F-3412-A4E8-BD968A75A07D]@0xfffffe00275bcf50->0xfffffe00275d0a3f\n dependency: com.apple.iokit.IOPCIFamily(2.9)[EC78F47B-530B-3F87-854E-0A0A5FD9BBB2]@0xfffffe0027934350->0xfffffe002795f3d3\n dependency: com.apple.iokit.IOReportFamily(47)[843B39D3-146E-3992-B7C7-960148685DC8]@0xfffffe0027963010->0xfffffe0027965ffb\n dependency: com.apple.iokit.IOThunderboltFamily(9.3.3)[B22BC005-BB7B-32A3-99C0-39F3BDBD8E54]@0xfffffe0027a5e3f0->0xfffffe0027b9a1a3\n\nlast started kext at 1915345919: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nlast stopped kext at 1774866338: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nloaded It seems that the DMA request address initiated by FPGA exceeded 32 bits, which was intercepted by PCIe root port and resulted in a kernel panic.This is also the case on macOS (M2). I have tried the following code interface: IOBufferMemoryDescriptor： a. withCapacity(bufferSize, kIODirectionInOut, true)； b. inTaskWithPhysicalMask(kernel_task, kIODirectionInOut, bufferSize, 0x00000000FFFFFFFFULL)。 The physical addresses of the constructed descriptors are all >32 bits; IODMACommand： a. withSpecification(kIODMACommandOutputHost64, 64, 0, IODMACommand::kMapped, 0, 0)，gen64IOVMSegments() The allocated IOVM address must be>32 bits, which will generate a kernel panic when used later. b.withSpecification(kIODMACommandOutputHost32, 32, 0, IODMACommand::kMapped, 0, 0)，gen32IOVMSegments() The allocation of IOVM failed with error code kIOReturnenMessageTooLarge. So after the above attempts, the analysis shows that the strategy of Dart+PCIe root port on macOS (Apple Silicon) is causing the failure of 64 bit DMA address transfer. I have two questions: a. Does Dart in macOS (Apple Silicon) definitely not allocate <=32-bit IOVM addresses? b. Is there any other way to achieve DMA transfer for FGPA devices on macOS (Apple Silicon)? Thanks！