[saagarjha]

Not really. The App Store installation first scans the entire bundle before installing the bits it needs, then it downloads the update and applies it, which goes through some not-very-optimized installation code that compresses the bundle on disk using zlib. This is ok for normal apps but for Xcode this can take a while. Blowing away the entire directory and just installing a fresh copy is usually far faster, if you optimize this you can do it in under five minutes.

[derefr]

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

[saagarjha]

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.

[derefr]

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

But isn't the key advantage of coreOS's model, a sort of green/blue deploy model for the OS — i.e. that it can write out the new updated OS release in the background while the previous release of the OS is running; and then, when it's done, "update" by just rewriting the EFI boot list to default to the new release — without even needing to reboot to perform the update, instead just saying "the next time you reboot, you'll be booting into the new release"?

There's no reason that an "OS update" under this model, should ever be a thing that takes over your whole computer, and then sits around with an "updating" progress bar, blocking startup. But that's what macOS does.

I think your intended meaning, was 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 abstractions — but doesn't give any of the key advantages.