file uri scheme

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 that need

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

Thanks for following up, and apologies for the delay-- this slipped past me. Here’s a repro asset I wrote that you can test directly: https://github.com/alexchuber/Assets/raw/refs/heads/main/Repros/triangleNegScale.usdz For additional reference, here's the USDA content of the asset (material omitted for clarity): #usda 1.0 ( defaultPrim = Root metersPerUnit = 1 upAxis = Y ) def Xform Root { def Mesh Triangle { matrix4d xformOp:transform = ( (-1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (0, 0, 0, 1) ) uniform token[] xformOpOrder = [xformOp:transform] int[] faceVertexCounts = [3] int[] faceVertexIndices = [0, 1, 2] normal3f[] normals = [(0, 0, 1), (0, 0, 1), (0, 0, 1)] ( interpolation = vertex ) point3f[] points = [(0, 0, 0), (1, 0, 0), (0, 1, 0)] uniform token subdivisionScheme = none } } The steps to reproduce are just: Add the asset to a new Reality Composer Pro scene. Open the same asset in QuickLook on iOS/macOS. Compare the facing direction in both views. You should see that the triangles appear to have opp

Same here. Anything in SwiftUI with a Slider will crash on macOS 26. Following this thread… FB20614181 also filed.

Thank you for the post. I noticed that you have posted the same issue again, this time with a link to the code. My recommendation, if I may, is to create a focused and simple project based on ContentUnavailableView https://developer.apple.com/documentation/swiftui/contentunavailableview. This project should demonstrate the exact behavior on iOS 26 and include a link to the code. This approach will make it easier to file a bug based on the project. If so, please share a link to your test project. 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. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Hope all this helps. Please let me know when is filed for me to check. Resources: https://developer.apple.com/documentation/TechnologyOverviews/adopting-liquid-glass Albert Pas

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.

The best way to ensure a problem is known and that a bug exists is to file one yourself. Bug Reporting: How and Why? has tips on creating a successful bug report. Even if the issue were to be known, additional bug reports let our teams to gauge the impact of an issue and help prioritize a fix for it.

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-allow