Failure to mount an FSKit volume *sometimes*

Am I doing something wrong here?

No, not really. I've actually seen variations of this failure across all macOS versions going back... well, basically "forever". The details of EXACTLY how it plays out vary across system versions, but the basic dynamics at work here are:

• LaunchServices "works" by detecting when apps/components "appear" in the system, then reading the data from those components into its database.

• The nature of the development process means that you can easily produce "new" apps with a speed and volume WILDLY higher than any normal user would.

• The entire system is regularly interacting with the LaunchServices database at exactly the same time you're changing that configuration.

...the net result of which is that "something" occasionally goes wrong, leaving bad data in the database.

I think I may be causing the constant unregister/register of the extension directly by rebuilding via Xcode. Or is it a problem with extensionkitservice?

It's certainly "a bug" and, if you haven't already, please do file a bug on this and post the bug number back here. These failures are considered serious and we do fix them. However, a few points I'd note here:

1. While I've seen these issues happen to many developers, they're much, MUCH rarer on end-user systems. The unique dynamics of the development process are the single biggest factor here.

2. The fact this "keeps happening" is a side effect of LaunchServices’ basic role, NOT a lack of attention or maintenance. That nature of LaunchServices’ role in the system means that it really only "fails" in one way ("something wasn't found, didn't launch, etc..."), which means lots of unrelated failures end up looking exactly the same.

Finally, just so this is clear, it's unlikely that there is any "deeper" failure or larger "harm" going on here. LaunchServices is simply failing to register a new build properly, which leaves it stuck with stale data. Doing this:

This would consistently repeat until I clean the build folder, rebuild, and run again. I would continue testing for a while, then at some point, mount would start failing again.

...is simply forcing a new registration cycle through the database, clearing the issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware.

Thank you for the response. I've just filed bug report FB20790194.

I would also like to add that this doesn't only happen during development. I can reproduce it pretty easily on release builds. If I archive my app and install it to /Applications on a non-development device (macOS 26.0.1) and then start repeating the following:

1. launch the app
2. mount
3. unmount
4. kill the app

After a few attempts, mount would start failing again due to the same error. I've included this information in the bug report.

Hello! The same issue can be reproduced on macOS 27.0 Beta (26A5388g). I'd like to add some additional info.

It seems like sometimes FSKit picks up .xcarchive files from Xcode/Archives on my machine, instead of my app's extension in /Applications. It also looks like this affects DerivedData too, as I'm forced to delete pretty much every intermediary folder, then deregister the extension from the system settings, restart fskitd and run the correct version of the app and then register the FSKit extension.

I'm not sure I understand the reason behind making the OS scan for the module extensions outside of /Applications, ~/Applications and /Library/Filesystems.

I'm not sure if I should create a new bug report or simply wait for this to resolve, but it seems like a somewhat serious issue.

Please let me know if you need additional info.

@Xinto As a workaround, when this happens to me, I use this command to try to clear the archived copies from the LaunchServices database:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -R -f -u ~/Library/Developer/Xcode/Archives

I've been using it in macOS 26.x, but haven't tested it in macOS 27.

It seems like sometimes FSKit picks up .xcarchive files from Xcode/Archives on my machine, instead of my app's extension in /Applications. It also looks like this affects DerivedData too, as I'm forced to delete pretty much every intermediary folder, then deregister the extension from the system settings, restart fskitd and run the correct version of the app and then register the FSKit extension.

Yes. This often happens when a developer is also a user of their own product, in which case my suggestion is that you "split" your bundle ID, using one bundle ID for your release product and another for your development builds. This removes the ambiguity, bypassing the issue.

I'm not sure I understand the reason behind making the OS scan for the module extensions outside of /Applications, ~/Applications and /Library/Filesystems.

This one is fairly easy, as the answer is basically "history". More specifically, Classic MacOS very actively avoided imposing any real constraints on how a user organized their files, including where applications were located. The system did include an "Applications" as part of its base configuration, but that directory had no special significance to the system and, in fact, its name was directly localized, so it was only actually called "Applications" on English systems. Users routinely implemented their own app organization schemes, which the system then had to support.

Mac OS X did introduce a more rigid layout, but it also had to work with user existing configuration, particularly when users regularly flipped between OS X and Classic. That's then carried forward to where we are today, as changing it is guaranteed to create as many problems as it "solves".

I'm not sure if I should create a new bug report or simply wait for this to resolve, but it seems like a somewhat serious issue.

I think the key point I'd stress here is the difference between user-level issues and problems tied to the app development process. Issues you're able to reproduce with "consumer" usage patterns are absolutely something you should report and that we should fix.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware