Does your app have the com.apple.security.cs.disable-library-validation entitlement? I think the Electron build tools people tend to use put that entitlement on by default (perhaps it probably shouldn't), which sometimes causes Gatekeeper to complain like this. Removing that entitlement, if you can, might solve the issue.

Thanks for that useful answer! It is indeed a corporate (well, a university) network, so I'll see if I can pass this along to IT. (More realistically, though, I'll probably be using a cable for the time being.)

@RickMaddy I think that might be a little out of scope for this thread. But in any case, I was able to update my macOS 26.1b2 VM to 26.1b3 via my logged-in Apple Account, so I don't think it's universally broken. Although my host is still on Sequoia 15.7.1. The closest thing I've experienced to what you're describing is an issue that I've seen for a while where logging in with an Apple Account hasn't been working for me if I have physical security keys enabled on my account for 2FA (FB19614234). Unfortunately if you're in this situation I don't know of any workaround other than removing all the security keys (and even if you re-enable them after logging in with the VM, eventually the VM will start complaining with pop-ups asking you to login again, although beta updates will still work despite this). This isn't new to 26.1, though. If this isn't the issue you're experiencing you might find better luck creating a new thread since I don't think many people with similar issues are going to find this reply buried in this thread.

So, for testing, I created a short Swift program that intentionally triggers a protection behind the platform restrictions entitlement: import Foundation import MachO var port: mach_port_t = UInt32(MACH_PORT_NULL) mach_port_allocate(mach_task_self_, MACH_PORT_RIGHT_RECEIVE, &port) mach_port_insert_right(mach_task_self_, port, port, mach_msg_type_name_t(MACH_MSG_TYPE_MAKE_SEND)) mach_port_move_member(mach_task_self_, port, 1000) In my testing, this crashes (as expected) with the EXC_GUARD exception type when com.apple.security.hardened-process.platform-restrictions is an integer set to 2 (just as the documentation and Xcode says). It does not crash when it is a boolean set to true. That suggests to me that App Review is mistaken. I'd try replying to them and link them the documentation pages, asking them to double check.

I was able to test on my own, and in my tests it seems like provisioning profiles now work in the VM. But it took some extra work than just recreating the provisioning profile. My host is on macOS 15.7.1 (24G231). tl;dr try making a brand new VM such that it has a new provisioning UDID and try again My "success" case was as follows: I had an older "clean install" VM on macOS 15.7, but it does have the newer provisioning UDID style. I did not add it to my account until just now, however. I manually added the provisioning UDID to my devices list on the developer website. Now, the new device that I just registered on the website has an identifier with lowercase letters (e.g. c28165661eb...) (before, it looks like it automatically set it to uppercase). I recreated the provisioning profile, and built an app using Xcode on my host. I transferred the built app into the VM via a shared folder. I opened the app, and the app extension worked successfully (in my case, my app itself doesn't use a provisioning profile, but its app extension does). The "failed" case (where I tried just recreating the provisioning profile) was as follows: I had a VM on macOS 26.1 beta 2, where I had already added the provisioning UDID on the site before. Under my account, any letters in the UDID are shown as uppercase (e.g. E784ACDA...) Since the device was already on my account, I just regenerated a provisioning profile and rebuilt my app. This did not work. My assumption is that the OS version here is not what matters. Perhaps the difference is the capitalization in the UDID on the website, and if so then maybe that's how they were able to deploy a fix via the website. Unfortunately, you don't seem to be able to change the capitalization of the UDID if it is already registered. If you disable the device and attempt to add it again manually, it will see that the device is "already" there with the uppercase capitalization and simply re-enable the faulty one. I would assume that you can recreate a new VM from scratch, such that it has a brand new provisioning UDID, then add it to your account. That seems like it should work. Also note that I did not test building with Xcode directly in the new VM to register the VM with my account; I added it manually on the website. I would hope that Xcode handles this properly, but if it still doesn't work, perhaps try manually registering the device on the website. Edit 2: I just ran another test where I allowed Xcode running in the VM to automatically handle the new device registration instead of doing that manually on the site, and the extension requiring a profile ran, with correct capitalization of the UDID appearing on the website. This was on a macOS 26.1 beta 2 VM. So then it seems like this should "just work" on a VM with a UDID that hasn't been registered to your account before. Edit: Also, if you don't want to make a whole new VM from scratch, you can do the following to cause the provisioning UDID to change: Make a clone of your VM. Run the clone. While the cloned VM is still running, run the original VM simultaneously. One of the VMs will have a new provisioning UDID. Use the VM with the new provisioning UDID. You can then delete the VM that has the old provisioning UDID, if you want.

Just received a reply on my feedback (FB19620814) regarding this issue: Please know that this issue should now be addressed. Please let us know if you're still encountering the problem. I haven’t had time to verify this on my own yet, however. Seems like it’s worth retesting.

A random guess: your command in your post doesn't have this, but if you're actually running the hdiutil command with sudo, the dev node of the disk ends up being owned by root which might lead to you seeing the issue at https://developer.apple.com/forums/thread/788609. I would think the solution then would be to use sudo mount but in my experience that hasn't worked which I think is a bug (FB18436584). If you run all commands like hdiutil and mount without sudo though, then it should work (at least it does on my machine).

Coming back to mark this as solved because it looks like automount now generally works when you return .usable as a probe result in macOS 15.6. However there still seems to be a few more subtle issues I've seen with probing in further tests: If you return usableButLimited, it won't try to automount at all, not even as read-only (FB19241327) If you return recognized(name:containerID:) or usableButLimited(name:containerID:), the name/container ID you return doesn't appear in places like Disk Utility or the diskutil command (FB19267291)

Did some LLM/AI put com.apple.developer.alarmkit there for you? I searched that entitlement on the web and the only result I got was this very forums post. If some made-up entitlement is applied then you might get an issue like that. What happens if you just remove that entitlement?

Does anyone have any ideas how to get photos stored in the Files app to open IN the Files app Press and hold on the file of the relevant file type, Open With > Preview with Quick Look.

It’s a bug. I saw this before too (FB18398975). I was told it’s fixed in macOS 26 beta 6 (25A5338b), and in my tests this appears to be the case.

Also, not sure if the original poster's app is sandboxed, but if your app is sandboxed then it looks like the situation is potentially worse: It seems like if the reason the file was quarantined was that it was modified by a sandboxed app, Gatekeeper instead says that the file is damaged and can't be opened, and should be trashed (FB19623735) rather than the malware warning. In that feedback I list similar user-level steps: Install Microsoft Word and Apple Pages from the App Store. In Word, create a new document and save the .docx on your Desktop. In Finder, right click > Get Info on the Word document. Set Pages to open that specific Word document (do not set Pages to open all Word documents). Double click the file to open it. Then Gatekeeper tells you the file is damaged (both Word and Pages should be sandboxed apps since they're from the App Store). IMO that wording is even worse since it would imply to a typical user that the file is somehow corrupted... not that it might be dangerous. Then they might lose data if they try to mess with it or simply delete data that is perfectly fine. If an astute user notices that it happens after they set a file to open with your sandboxed app, it works once (say it starts out unquarantined), and then the system tells them it's damaged after any modifications are made, they're likely to blame your app, too, rather than the system's antimalware checks. For reference this is the wording of that alert: I get the security implications of having a file set to open with some arbitrary app (I mean, regardless of the file type, if it contains the contents of a script it could be dangerous if you open it with an unsandboxed script interpreter app installed on the system - if a sandboxed app could do that then that would be a fairly simple sandbox escape) but I hope a better balance exists... or at least that the wording is changed.

For anyone else who finds this thread, FB18614667 is fixed in macOS 15.6 RC (24G84), and in my test I no longer needed to include FSSupportsKernelOffloadedIO for metadataRead to work in that version.

And you’re able to make that work with App Sandbox enabled? Nice! Well, mostly. We already have a mechanism to auto-detect Java installs in some standard locations. The most common is the standard Java install location at /Library/Java/JavaVirtualMachines which the sandbox seems to let us access by default. Then some other locations we check can be allowed via file temporary exception entitlements. Only part that doesn't work^ is choosing arbitrary locations via file picker since that doesn't give executable access, unfortunately. ^ Well, it's possible in that we could use the SBPL temporary exception with a regex rule to allow execution in all Java bundles since they tend to be named/structured in a certain way. Though from what I understand the SBPL temporary exception isn't like the others since SBPL itself isn't supported, but at least this is the least common case and we can recommend putting JVMs in standard locations instead of doing this. And even if we take the risk, if it breaks at some point we will still have the supported alternative method to point people to instead. But for smaller developers, or folks working on open source projects, this is a challenging task. Hmm, yeah. This project uses hosted GitHub Actions CI for most of this stuff, and it doesn't seem like they make beta versions of macOS easily available to run actions on. So practically they'd need to be run locally by someone. :( Will definitely still try to investigate ways to make testing these fragile parts easier, though. But, you know, it’s either live with this trade-off or go work on yet another boring to-do list app, and I know which one I’d rather be doing (-: Ha, that's certainly a motivator. The challenge is part of the fun (at least until it breaks) :)

FSSupportsKernelOffloadedIO Oh, interesting. This actually came up when I filed a different bug where kernel offloaded IO wasn't working (FB17773100). At first it was closed because I didn't include that key (since it wasn't documented or in the template), but it still didn't work after adding that key until macOS 15.6 beta 3, where it's now fixed. Interesting to see that metadata{Read,Write} is linked to that at the moment. It was indeed the case that adding that key made it work. the FSKit team is working very hard to ship as many fixes as possible in macOS 15 (not just macOS 26) Yeah, I have noticed that the FSKit team has generally been quite responsive and good at updating the statuses of feedbacks I've filed recently. Highly appreciated, by the way! No, or at least not exactly... Interesting insight! I mostly come from a background (or lack thereof) where I kinda just started working with filesystem code first with FUSE as a small thing (for a school project) and found it interesting, then FSKit coming out gave me motivation to try to go deeper into it in my own time. Thus I never really used the older KPI to create filesystem kernel extensions and thus don't have some of this background knowledge, which makes filling in some of the gaps in the documentation a bit more challenging. Thank you to you and the team for being helpful in answering FSKit-related questions here on the forums, it's very helpful.