Is there a reason that these big installations of OS "components" aren't just distributed as APFS .dmg files, where the (pre-compressed) APFS volume in the disk image just gets shoved into your OS APFS container and wired up to automount at its directory mount-point?

(Basically like how Ubuntu's Snaps work filesystem-wise; but interacting directly with the logical-volume manager to create volumes, rather than keeping the disk image around as a file in your filesystem.)

For that matter, given that the APFS OS volume is read-only, is there a reason macOS hasn't yet transitioned to the coreOS model where OS updates just are just Courgette-alike binary diffs that construct a new OS volume beside the old OS volume atomically by stream-merging the old volume with the patch, and then blessing the result? Or the game-console software update model where the base-images of things are immutable, and instead updates are their own read-only volumes that get overlay-mounted on top of the base images when you mount the base images? (I know macOS can already do the latter for security hotfixes; it's strange that they don't use that capability for regular updates.)

Xcode is not an OS component, but it could certainly be distributed as a APFS disk image that could be union mounted (this is actually how the watchOS and tvOS SDKs work today, plus Apple does this internally). I suspect they use XIPs to get that signature (which, tbh, is kind of useless) and compress it hard, but IMO these tradeoffs are not great. I have a long-term goal of writing out to a disk image myself, but my motivation would be to bypass filesystem performance bottlenecks when decompressing the archive.

> For that matter, given that the APFS OS volume is read-only, is there a reason macOS hasn't yet transitioned to the coreOS model where OS updates just are just Courgette-alike binary diffs that construct a new OS volume beside the old OS volume atomically by stream-merging the old volume with the patch, and then blessing the result?

To my knowledge this is pretty close to how updates work today.

> To my knowledge this is pretty close to how updates work today.

But the key advantage of this model is a sort of green/blue deploy model for your OS — when you do it, you can construct the new updated OS release in the background while the previous release of the OS is running; and then you "update" by just rewriting the UEFI boot priority to default to the new release. There's no reason that an "OS update" should ever be a thing that sits around and blocks startup.

I think your intended meaning, is that the current model involves a binary diff that gets used to patch the OS volume, while the OS is booted into the recovery volume. Which, yeah, uses kind of the same ideas, but doesn't give any of the same advantages.