Hmm. I tried something like the code you sent, and same as you, it compiled. But when I changed iOS to macOS in the availability macro (which I assume is what you intended to write), then I get the compile error... weird... this is also the case if I change FSVolume.MountOptions to something like Int, so it's not because the FSKit types are macOS only. Here's some sample code that reproduces this (also added the code to my feedback): @objc protocol SwiftProtocol { @available(macOS 26.0, *) @objc optional var requestedFoo: Int { get set } } class ReproduceBug: SwiftProtocol { @available(macOS 26.2, *) var requestedFoo: Int { get { 0 } set {} } }

[quote='884798022, DTS Engineer, /thread/807771?answerId=884798022#884798022'] I don't think you actually need to use an availability macro at all. [/quote] In this case there's a compile error if I don't include the macro as my minimum deployment target is macOS 15.6 and FSVolume.MountOptions is not an available type in that version. [quote='884798022, DTS Engineer, /thread/807771?answerId=884798022#884798022'] Not sure why that's happening, as "requestedMountOptions" should be optional, so you don't need to implement it all. [/quote] Yeah, it was quite weird... I actually had a drafted FB about that compile error that I haven't cleaned up and submitted yet. I found some time to do that (FB22525990), though as long as putting 26.0 in the macro doesn't cause any weird or undefined behavior then it shouldn't be that big of a problem. Thanks for helping out with this!

FB22267894 is fixed in macOS 26.5 beta 2. Now code like @available(macOS 26.0, *) var requestedMountOptions: FSVolume.MountOptions { get { return [.readOnly] } set {} } has the desired effect. Also, as a follow-up question, is @available(macOS 26.0, *) safe in this case? I saw in the macOS 26.4 release notes that the availability version is wrong and actually 26.4, not 26.0 (171914656). However using @available(macOS 26.4, *) fails to compile [1], which seems kind of odd. Will that cause problems in macOS 26.0 through 26.3? [1] with the error Protocol 'Operations' requires 'requestedMountOptions' to be available in application extensions for macOS 26.0 and newer

Via a reply to FB22286320 last Friday I was told to verify it is fixed in macOS 26.4 (25E246). Not sure if they meant to make the VM on a 26.4 host or using the 26.4 restore image, but the latter still doesn't work on a Sequoia host without manually installing the mobile device support package (they still don't auto-download from the software update server). If they meant the former, well, I don't think that was under dispute ;) although given that 26.4 is released by now I suppose it really is only affecting Sequoia hosts at this point.

I'm still seeing this on the release version of macOS 26.4 (25E246). I looked at this a little more, and I don't think requestedMountOptions is actually being read. I changed my test implementation to do something like this: var requestedMountOptions: FSVolume.MountOptions { get { Logger(subsystem: "com.kpchew.FSKitSampleApp", category: "default").log("Reading requestedMountOptions") return [.readOnly] } set {} } and I never see the log message. Edit: also I'd like to add that the documentation says requestedMountOptions should be read after the extension replies to mount. However I don't actually see either mount nor unmount get called either (FB22343796), so maybe that's related?

In zsh a highlighted % means there's no newline at the end of the output. It's not literally a % in the output and shouldn't affect anything if you're using the output programmatically. e.g. if you direct its output to a file you won't see a %

During the beta cycle, developers can get the required MobileDevice by installing the latest Xcode seed. That's problematic on macOS 15.x because Xcode 26.4 now requires macOS 26.2. However, would it be possible to open the Xcode.app/Contents/Resources/Packages/MobileDevice.pkg manually on a macOS 15.x machine to get the required mobile device files? Once the OS is released, either: That doesn't seem to match my experience. macOS 26.4 is now out, and I've updated to macOS 15.7.5 (24G624), but when I try using the restore image of the release version of macOS 26.4 to make a VM, I'm still prompted to install the mobile device files and it still says that they aren't available from the software update server.

maybe it would work to make a VM with an earlier macOS version then update it? Regarding this idea, my storage issues cleared up with the final release of macOS 26.4 (the new update required about ~5 GB of VM in my pre-existing VM, but the RC wanted about ~35 GB for some reason). I was able to update the VM and run it. So, it does seem like a possible workaround is to install a VM with an older version of macOS and then use Software Update inside the VM to update it to 26.4.

On my macOS 15.7.4 machine: $ pkgutil --pkg-info-plist com.apple.pkg.MobileDevice <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>groups</key> <array> <string>com.apple.findsystemfiles</string> </array> <key>install-location</key> <string>Library/Apple/</string> <key>install-time</key> <integer>1771452321</integer> <key>pkg-version</key> <string>4.0.0.0.1.1762585687</string> <key>pkgid</key> <string>com.apple.pkg.MobileDevice</string> <key>receipt-plist-version</key> <real>1</real> <key>volume</key> <string>/</string> </dict> </plist>

AFAIK there’s no magic here. And I tried reproducing this on my main work Mac and didn’t have a problem. @DTS Engineer When I have this issue, it also comes with a prompt that appears offering to download the device support files, but this fails because the files aren't available from the software update server. Given that you're an Apple employee, is it possible that your work Mac has access to an internal software update server that offers the required device support files, but that the public software update server doesn't?

I'm also encountering this trying to make a 26.4 RC VM on a macOS 15.7.4 (24G517) host (a M3 MBP) (FB22286320). I have a VM working from a previous 26.4 beta that was originally on an earlier version of 26, but I wasn't able to upgrade it to the RC via Software Update due to storage constraints :( maybe it would work to make a VM with an earlier macOS version then update it? I haven't found time to test whether that works, though.

[quote='880540022, DTS Engineer, /thread/807771?answerId=880540022#880540022'] I think you're seeing #2, but I want to confirm that. [/quote] AFAICT it seems to be #1. There was a small issue in the test project I submitted to FB22267894 [1], but when that is changed, if I set a breakpoint at createItem(named:type:inDirectory:attributes:) (for example) and then touch /Volumes/Sample/hi, I will reach the breakpoint in createItem and see the error that function outputted in Terminal. For example if I change createItem to return EIO, the touch command in Terminal then shows an input/output error. [1] Namely, my lookupItem sample implementation returned ENOSYS for any lookup other than the single static file implemented in the test file system. If it is changed to return ENOENT instead, then I can reach the createItem breakpoint.

I noticed that macOS 26.4 beta adds requestedMountOptions with the ability to set the readOnly mount option, which seems like exactly what I wanted! Unfortunately, it didn't seem to have the desired effect and non-functional write actions still show up in places like the Finder :( (FB22267894) Hmm... Maybe? Turns out my memory was wrong and APFS was actually adopted in iOS 10.3, not 8.3. It was also way after the iOS 10 days (this happened in 2022), so probably something else.

Can you confirm that this is happening in macOS 15.7.3 (24G416) in upload a new sysdiagnose if it is? The FSKit team believes it should have been fixed in that release. Via a response to FB21305906 I was recently told that this issue was fixed in macOS 26.4 beta (although, I didn't see the issue in 26.x at all via updates/deletes on the parent app). Unfortunately I was also told there's no plans to backport the fix to Sequoia and got the dreaded This Feedback will no longer be monitored, and incoming messages will not be reviewed. so I'll just have to deal with it, I suppose :/ But luckily this workaround The way to prevent this is to think in terms of your "app", NOT your app extension. The high level system[1] won't allow you to move (much less delete) an open application, nor should it be updating[2] it while your "app" is running. 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. Did seem to work out when having a process without a GUI run while the volume is mounted (at least, Finder definitely prevents me from deleting the app while it's open - a bit more annoying to test an App Store update proper but assuming they're at a similar level like you say then it seems like it should work), so I'll mark this as solved.

[quote='810660021, SamanthaValverde, /thread/810660, /profile/SamanthaValverde'] App status: Ready for Review (unchanged for 2 weeks) [/quote] That means you only made a draft submission and haven’t submitted your app If it’s submitted it should say “Waiting for Review” or “In Review” edit: also, for your actual question, my experience is usually that I’m waiting for review for about a day at most and in review for about 1-2 hours However, I did recently have to wait about 3 days for the review to start, although that wait did include the weekend and I assume there were also more submissions than usual due to the age rating emails they sent out