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.
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|3 years ago
derefr|3 years ago
(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.)