AppEx lifecycle improvements

Question

Created 7h

Replies 6

Boosts 0

Participants 2

This post is from the WWDC26 File Systems Q&A.

Outside of a very narrow happy path, Filesystem Extensions can leave the system in a bad state that can be hard to get out of:

For example, a hanging Volume call can leave any process attempting to read from it permanently stuck (no timeouts, process is unkillable, ps / pkill / pgrep themselves may start hanging).

When it comes to installation, FS AppEx are registered with two subsystems afaict (LaunchServices and fskitd) — those two states can get out of sync, and typically cannot be repaired manually. In particular, the only way to reset fskit state seems to be to kill it (notably, disabling SIP is required to launchctl kickstart it, but sudo killall fskit works like a charm).

AppEx installed/enabled state seems to be per-user. When mounting as root, fskit queries a different state (implying that a FS may be enabled for an admin user ie. John Doe, but not from the perspective of a root SMAppService — even when using launchctl asuser/bsexec to attempt to replicate the security context of John Doe's login session at their behest).

The actual question here is hard to formulate... are there any plans to make FS AppEx behave more like the rest of the platform? More consistent/helpful/centralized logging (it is currently spread across multiple targets and as much as the "boom" and emojis are entertaining, on day 14 of debugging transient failures, it does get old).

Making a .pkg installer with an FS AppEx inside prevents the AppEx from being installed through the prescribed happy path (simply having the user launch the containing .app) since it gets pre-registered via LaunchServices. In fact, building an AppEx through XCode automatically registers it with ls, making real-world testing of AppEx really difficult...

The sheer breadth of subtle challenges in shipping a working, reliable FSKit-based filesystem on macOS has prevented me so far from filing tidy, individual bug reports, and for this I apologize, but: if you have a roadmap of "reliability improvements / behavior normalization / edge case resolutions" to share today, I'm sure many of us would be eager to read it.

Answer 1

Systems Engineer OP

Apple

6h

You cover a number of points here, and each of them will have a unique answer. Please send feedback for each point, so that we can focus a response to each specific issue.

Answer 2

fasterthanlime OP

6h

Will do, thanks!

Answer 3

Systems Engineer OP

Apple

6h

When it comes to installation, FS AppEx are registered with two subsystems afaict (LaunchServices and fskitd) — those two states can get out of sync, and typically cannot be repaired manually. In particular, the only way to reset fskit state seems to be to kill it (notably, disabling SIP is required to launchctl kickstart it, but sudo killall fskit works like a charm).

What version of macOS did you work on? We made improvements in this space for macOS 26.5. fskitd should do a better job of staying in sync with the LaunchServices database.

Answer 4

Systems Engineer OP

Apple

6h

AppEx installed/enabled state seems to be per-user. When mounting as root, fskit queries a different state (implying that a FS may be enabled for an admin user ie. John Doe, but not from the perspective of a root SMAppService — even when using launchctl asuser/bsexec to attempt to replicate the security context of John Doe's login session at their behest).

AppEx state is per-user. In fact, root's LaunchServices database is typically very empty, containing only system applications. This property is part of how LaunchServices operates and is something FSKit takes as given. Also, our current consent/approval model only asks a user for approval for themselves.

Why are you having root do mounting?

Answer 5

Systems Engineer OP

Apple

5h

The actual question here is hard to formulate... are there any plans to make FS AppEx behave more like the rest of the platform? More consistent/helpful/centralized logging (it is currently spread across multiple targets and as much as the "boom" and emojis are entertaining, on day 14 of debugging transient failures, it does get old).

On the "question," as above, I feel like you have multiple. I look forward to your feedback.

On logging, what would be more helpful? The work is spread across multiple components. Personally, I find that different problems drive me to looking at different sections of the logging. So the things I care about today are things which will get in my way tomorrow.

I would love to understand how logging could be structured to help you.

Answer 6

Systems Engineer OP

Apple

5h

Making a .pkg installer with an FS AppEx inside prevents the AppEx from being installed through the prescribed happy path (simply having the user launch the containing .app) since it gets pre-registered via LaunchServices. In fact, building an AppEx through XCode automatically registers it with ls, making real-world testing of AppEx really difficult...

How does the app being pre-registered harm the user's experience, or real-world testing?

I appreciate that many parts of the system may be aggressively "helpful," and that they give you a different experience from the end user. But I think that's going to be true of many subsystems.

One thing which may be a helpful path is to use the new Devices.app and spin up new, clean computers to try things out on. I realize it's not the same as real hardware, but it may be a helpful step forward.