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

[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.