We are unable to process your request

Thanks for the post. I see you filed a bug, you have provided some code in the bug, thanks for that, but may I ask to upload a focused project showing the issue? If so, please share a link to your test project or better upload it into the FB issue That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

Thanks so much for the comment, adding a post here as I would ask you to give engineering sometime to investigate FB20605681. You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

Thanks a lot! ...adding external-accessory is not changing ANYTHING about how your app wakes/sleep in the background. You will not be allowed to use it, but that's because it's not relevant to your app. In my tests 2 weeks ago I (might be by my mistake) saw a correspondence between external-accessoryand the facts of callbacks from IOServiceAddMatchingNotification. Or at least correlation with the moments of such callbacks at the time of application moves from background to foreground. Having your unambiguous statement I tediously rechecked my environment now and I found 2 possible weak-points: A) I conducted the tests above having 2 identical DExts (for 2 different but very similar UserClient-Apps) formally enabled in Settings|Applications|Drivers. Though, of course, only one UserClient was active. I shall repeat the test (on near weeks) with single DExt physically installed. Another Q&A in TestFlight was being conducted in distant country. I shall reconfirm about the environment there. B)To distinguish t

Yeah, I see the following error when trying to prompt the on-device foundation model from within a device activity report extension (DeviceActivityReportExtension), which I believe is the same as what you mentioned: establishment of session failed with Unrecognized underlying error: Underlying connection was invalidated. Reason: failed at lookup with error 159 - Sandbox restriction ModelManagerError: got unrecognized error Underlying connection was invalidated. Reason: failed at lookup with error 159 - Sandbox restriction I am pretty sure that is as-designed. To give you more context, when responding your prompt, the model needs to communicate with the model manager, which is a system daemon that manages the inference requests. To protect the user’s privacy, however, the system doesn't allow a device activity report extension to move data outside the extension’s address space, and that prevents the model from creating a connection to the model manager. Having said that, if you have a compelling case

Could you share your understanding of the crash and give any hints on how we can fix it? So, let me actually start by commenting on this: At first, we assumed that the issue is with hardware. The first thing to understand here is that DEXTs are FULLY capable of panicking the kernel and probably always will be, particularly PCI DEXTs. The main benefit DEXTs provide is that they DRAMATICALLY improve overall system security and risk by constraining the range of what it's POSSIBLE for a component to do. Your DEXT only has access to a very limited set of kernel data, so that's the ONLY kernel data your DEXT interacts with. It's possible for a network DEXT to disrupt the network stack, but it's very difficult to see how it would disrupt the file system. However, your DEXT is still being given access to many of the same resources it would have access to as a KEXT, and many of those resources are inherently dangerous. In the case of the PCI family, that issue is quite direct— I don't know of any way to build a safe A

Given this hard evidence from ioreg, are there any other mechanisms or sandbox restrictions that could be preventing our app from seeing this active IOKit service? There are more details below, but the bottom line is that I think the problem is that your search code is incorrect, not that we’re blocking access to the kernel. I can say that there isn't any mechanism on macOS that would hide a specific service, particularly not a service that wasn't ours. Keep in mind that the tree structure of IOKit means that blocking access to an arbitrary object can have bizarre and very unpredictable consequences, particularly in the mass storage stack. App Sandbox: We confirm that com.apple.security.app-sandbox is set to false in our app's entitlements. This alone did not solve the issue. This does work and is actually how our sample project works. Have you tried modifying that sample to find your driver? Result: Failure. Even with this entitlement configuration, the call to IOServiceGetMatchingService(DriverKitAcxxx) sti

Hello, Please send us an enhancement request to provide RealityKit support for watchOS.

Thank you for providing all that, I saw you attached an Objective-C file in the FB, I didn't see a project. You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

Hi Kevin, Thank you for the detailed response. Here is a summary of our tests based on the solutions you proposed: Regarding the userclient-access Entitlement: We discovered a human error in our initial entitlement request (we had entered the wrong Bundle ID). We have submitted a new, corrected request with the proper DEXT Bundle ID and are currently awaiting its approval. Regarding the Temporary Solutions: To continue development while waiting, we tried your other suggestions, but are still blocked. App Sandbox: We confirm that com.apple.security.app-sandbox is set to false in our app's entitlements. This alone did not solve the issue. IOKit User Client Class Temporary Exception: We implemented your third suggestion precisely. Our app's .entitlements file for this test was configured exactly as follows: com.apple.security.temporary-exception.iokit-user-client-class IOUserUserClient com.apple.security.app-sandbox com.apple.developer.system-extension.install com.apple.security.get-task