[quote='869273022, JohnC2, /thread/809952?answerId=869273022#869273022, /profile/JohnC2'] Are there any examples of Apple designed apps that behave in this manner? I can't seem to find any. [/quote] I don't know if most of the password entry fields in Apple apps even have a reveal password button for sighted users (I could not find one on a random one I checked), but Apple's Passwords app allows you to reveal passwords, including when using VoiceOver, and reads the password aloud when using VoiceOver. [quote='869273022, JohnC2, /thread/809952?answerId=869273022#869273022, /profile/JohnC2'] These types of buttons in general to me seem to defeat the purpose of "secure text entry". [/quote] That seems more like an argument against the reveal password button in general than an argument against showing it to a VoiceOver user. Which is certainly an opinion you can have, but it's not really accessibility-specific. I'd agree with both your accessibility team and the above engineer that it's worth having the option there in the screen reader case, if you're going to have it there at all. If a VoiceOver user clicks that button, they would probably expect it to be read aloud. Keep in mind that someone may be using e.g. headphones or simply be alone and consider it worth any "risk."

Can you confirm that this is happening in macOS 15.7.3 (24G416) in upload a new sysdiagnose if it is? It is, unfortunately, still happening in a macOS 15.7.3 (24G416) VM I'm testing in. I attached a new sysdiagnose to FB21305906. I don't know what (if any) user interface you've implemented, but having some kind of "app experience" running while your volume is mounted would be the most direct way to prevent these issues. Hmm, ok. So presumably if I just wait for a "fix" I might be waiting for a while. Right now my own UI is just a guide to enable the file system extension, so there's essentially no reason at the moment for users to keep the app itself open after that point. It's pretty much just in an app because it's necessary for distribution. Maybe I could have some GUI-less mode of the app open whenever the extension mounts something and then kill that instance on unmount? But between sandboxing and App Review complications I don't know if that's actually feasible.

Makes sense, so seems like what I saw back then [1] almost certainly wasn't at the APFS layer, then. one follow-up comment for the "haters" out there: Ha, well I would hope that someone looking at an FSKit-related question on the forums would know enough about file systems to understand why that would make sense, though I suppose you never know ;) COW is definitely saving me more space on my machine than whatever is reserved for that purpose. [1] If you're curious it was an old Apple Watch I had that got stuck in a boot loop after restarting it to try to fix some "crashy app" behavior, and IIRC there were low storage alerts shortly before that happened. Definitely way after the iOS 8 days.

Thanks! That clears my confusion up. Right now I'll just be focusing on the layers relevant to an FSKit module. I wasn't even really thinking of the case where reported total bytes != physical total bytes, but that example makes sense. As a real-world example, copy-on-write (COW) file systems like APFS work by pushing "all" changes out as writes which are then applied, but that also means that it's possible to put the file system into a state where it can no longer be modified. Modification would require free space, so if all the space is gone modification becomes impossible... and that INCLUDES deleting files. The simplest solution to this is exactly what APFS does— set aside enough space that you'll "always" be able to delete files, then increase your used count so that the volume is "full" before you ACTUALLY run out of "all" space. Huh. Out of curiosity, did APFS always do that to prevent that issue? I vaguely remember seeing an issue like that at a user level years ago (although, I don't really have any evidence to really prove that that was the specific issue that happened, so maybe not). In any case, going back to the original issue, I wonder if that's related, or maybe that's a completely separate issue. I think we can file this under "completely separate."

My issues might even be better solved with FSActivateOptionSyntax, but I don't know where to find the docs for it. Or how to propably use it. Yeah, that's probably meant to be used for your situation. I think you're supposed to be able to provide a path then you can get a security-scoped URL that you can use to access that specific path while sandboxed. I briefly looked at that a while ago but I don't think most of the Info.plist keys are documented right now. Most of the "documentation" right now is just scouring the forums or Apple's open-source FSKit extensions for examples (or, if you're lucky, replies to your feedbacks), which isn't too great. My (untested, could be wrong) assumption was that if you were to set something like <key>shortOptions</key> <string>abc:d:</string> Then on the command line you'd be able to pass options like -a or -b, while -c=arg and -d=arg both take additional arguments. I never needed it for my own extension though so I didn't look too hard, but the forums post you listed suggests that the ability to get a URL from them didn't work for that OP, so I don't know if it would actually work for you. That sounds like a bug but it looks like the OP of that thread disappeared so it's not too clear what happened there. If it doesn't work or you can't figure it out then you should probably file a bug and post it here; an Apple employee is more likely to be able to help you that way. In my experience the FSKit team has been pretty responsive to feedback when I also post about it on the forums, and even without posting. Or, just keep using the sandbox exception and call it a day. The only question remaining is: The test question. Tests... I should write some for my own module... Anyway, I think the better option is to try to separate out the logic for your file system into their own unit testable functions, then test those separately instead of trying to test it by mounting a whole volume with FSKit. Then you'd sidestep the issue around FSKit being weird when being automated. Your goal isn't really to test FSKit, it's to make sure your own file system logic is good, so I think for this kind of codebase that should be mostly sufficient. Unfortunately to do something like the analog of a "UI test" for a regular app (but I guess without the UI... an integration test?) I don't know how to automate it very well, but ideally your unit tests cover most of the things you do need to test.

By the way, it's usually best to make a reply instead of leaving a comment. Comments are easy to miss and usually don't create notifications. Do you know whether I can use com.apple.security.temporary-exception.files.absolute-path.read-write with /? I think it should work, although I haven't tried it myself. how do I log from the extension? If I use the standard logging framework, no logs arrive in the console app. Not sure exactly which "standard logging framework" you're referring to (there's a lot of them), but I've been able to use Swift's Logger API (from os.log, I think if you're in Obj-C you'd use os_log) from my extension and it acts like logging from a regular app. If you're trying that and it's not working, then are you logging on the debug or info levels? Those don't show up in Console's streaming view by default unless you enable them in the Action menu. The more severe levels do show up by default.

I think FSKit modules have to be sandboxed, but since you're not planning to be on the App Store and thus don't need to care about App Review, have you looked at the temporary exception entitlements (https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html)? You might find the file access ones useful.

Volume does not implement both maxFileSizeInBits and maxFileSize, while one of them must be implemented. Implementing this didn't seem to change the result. But I definitely do need to fix the sample FSKit project I've been copying as a base for all of these bug reports, then! Have you looked at what the actual block size of that device is and what FSBlockDeviceResource.blockSize is? Both physicalBlockSize and FSBlockDeviceResource.blockSize are 512 on the disk image. However, there are other issues. Your testing with a disk image, but the disk image block size is 0x200/512, NOT 0x1000/4096. If you’re looking at those values from the volume side, you may get 4096, but that's because the volume changed what stat returned, not because it's actually true. ... In your particular case, this also means that the stat value you're returning is 4x larger than the underlying FSResource size. That isn't necessarily "wrong", but that's because the VFS layer will basically believe "anything" you tell it, not because that's what you wanted to do. So, as context for where 4096 comes from, in my real extension I read the logical block size that the filesystem uses from a value stored on the superblock on disk. Most of the time that value is 4096 bytes, which is why I chose that value for the sample project. My assumption is that this value is supposed to be set to the logical block size that my file system uses? In which case that would be this larger value, not the physical block size on the device. I suppose a lot of my confusion lies from how FSBlockDeviceResource.blockSize is described as "The logical block size, the size of data blocks used by the file system," which I understand to mean that in my case, I should be able to set it to the value stored in the superblock (let's say that's 4096). But since I can't set that directly, I figured that setting the volume statistics' blockSize would report that higher value at the volume level in statfs then feed back to that value, but that didn't seem to happen since it remained at 512. Finally, on "f_ioSize", it's also possible that we're intentionally capping that size to 1MB. Hmm, but that would be a strange reason in this case, wouldn't it? In the sample project I set stats.ioSize = 524_288 which is half of the default value. So it should be within that limit, still, unless you mean that it's just always kept at 1 MB. Although I have seen the same behavior (ioSize always at 1MB even if set to a lower value) in my real project that does implement kernel offloaded IO, so it seems a bit confusing if that value can be "set" but doesn't actually do anything.

Thanks for the update! That's useful to know, I'll look out for any changes in future updates. there appears to be a breakdown in the logic which means that flag isn't getting set automatically I've also been seeing some other issues related to certain things I set in the FSKit API not showing up in statfs (mainly the volumeStatistics's blockSize and ioSize, FB21106711). I wonder if that's related, or maybe that's a completely separate issue.

I think the tricky part here is what "support" here actually means. Yeah, I was actually having a bit of trouble trying to think of a title for this post (and for the aforementioned FB21068845). If either of those behave differently, then that's a HUGE bug that we'd need to fix ASAP. I didn't actually check those two (write isn't implemented at all in my filesystem). While it would take a little longer to check actual writes I just checked and FSBlockDeviceResource.isWritable is returning the correct value (false) when mounted as read-only, so I think that part is okay, at least! I think the best approach here is to support permissions (FSItemAttributeMode), and then ALWAYS return a configuration for all objects that prevents writing and fail any attempt to modify mode I actually have tried this. There's this code in my real project: if request.isAttributeWanted(.mode) { // FIXME: not correct way to enforce read-only file system but does FSKit currently have a better way? let useMode = readOnlySystem ? mode.subtracting([.ownerWrite, .groupWrite, .otherWrite]) : mode attributes.mode = UInt32(useMode.rawValue) } I suppose I can remove that FIXME if that's the case! However, that doesn't remove the relevant options from Finder, and users can still attempt to do these actions. It'll ask me to first authenticate with my admin password, then fail if I do. Edit: actually, I think the admin prompt is because of the access check. When I modify the sample project I sent into FB21068845 to just return a mode of 0o555 then it still just presents me the option to use those options and doesn't ask for admin, but still returns errors. The other annoyance I see with this solution is that if I use Finder (or something else like cp) to copy files out of this read-only disk onto some other disk that is read-write (like the internal SSD), then the destination file also has the read-only mode. Please file a bug on this (specifically, msdosfs's behavior) Here you go: FB21094219

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.