I'm trying to test the update process for an app containing an FSKit module that I'm distributing on the Mac App Store. (I'm also distributing the same app directly with Developer ID, but here I'll focus on App Store because that's the behavior I've been looking at first.) To do that I'm using an internal tester group on TestFlight and then testing an update with TestFlight. Below is the behavior I'm seeing on macOS 15.7.2 (24G325).
I've noticed that if an app update is triggered while a disk is mounted using the FSKit extension, the disk is automatically unmounted without warning (FB21287341). That's already undesirable itself in my opinion, but on top of the unmount, there are two other problems:
- That unmount doesn't seem to be a "clean" unmount and doesn't call functions like
synchronize(FB21287688). Now, in my case, my app only provides read-only access, so that doesn't actually matter much in my case. However, I'd imagine if I were to add write access at some point in the future, this would go from "doesn't matter" to "very bad." - I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of "disk-related actions" (for lack of a better term) to freeze (FB21305906). For example, a use of the
mount(8)command or trying to mount a disk at all freezes, and opening Disk Utility stalls on a "Loading disks" spinning indicator. This happens until the Mac is rebooted. I did notice this issue once while testing updates via TestFlight a few times.
The same applies if I simply delete the app with Finder instead of updating it.
Is there a way to prevent the extension's process from terminating in this case and/or another workaround I could use without waiting for a macOS update to hopefully change this behavior?
And does observing this kind of behavior with TestFlight's update behavior suggest the same thing could happen on the App Store with its automatic updates? I'm concerned that pushing an update via the App Store will unexpectedly unmount disks or cause the system-wide issues described in FB21305906 at a random time, which is a pretty big disruption for users.
So, let me start with the critical one here:
I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of "disk-related actions" (for lack of a better term) to freeze (FB21305906).
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.
In terms of the other two bugs (FB21287341 & FB21287688), the answer is basically "yes, that's what's going on". FSKit is built on top of our standard app extensions infrastructure, which is then terminating your extensions as part of its normal process for handling these cases. That's certainly not ideal for something like volume mounting but changing the behavior is significantly more complicated than simply fixing "a bug".
However, that does mean you have an option here:
Is there a way to prevent the extension's process from terminating in this case and/or another workaround I could use without waiting for a macOS update to hopefully change this behavior?
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.
[1] I say "high level", because there's a split between what the high level user interface will allow and what the kernel/Unix layer will permit. So, for example, the Finder won't let you move or delete an open app, but Terminal certainly will. However, this split actually "works" in both directions so, for example, deleting a running app doesn't actually affect that currently running app (at least not directly).
[2] Anecdotally, it's possible there's a TestFlight bug in this area, but I haven't confirmed that.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
