I just want the new changes to Safari and Notes while I don't care about the other changes, why not have Safari be a normal application downloaded from the App Store, like the rest of us pleebs have to do when publishing apps?
Plus of course everything is tested together (which is what Linux distros also do. They update their apps for minor releases and bugfixes but not major releases for the same distro).
> Plus of course everything is tested together
That makes sense, Apple's QA department seems to be held together with tape for the last decade or so, as every new update seems to break something, so maybe they're trying to make it as easy as possible now in order to recover.
Not needing to bundle dependencies that you know are provided by your OS environment?
Easy to investigate and fix bugs (You don't need a VM of every MacOS version on your machine)?
They might also see it as an incentive - perhaps new app features act as driver for OS adoption.
From a security perspective decoupling from OS updates seems advantageous.
[1] https://support.apple.com/en-mk/guide/deployment/dep93ff7ea7...
i.e. they may have started out that way, but almost nothing is gained thinking about this history today, despite it being factually correct.
- Darwin is developed "as" a BSD — a vertically-integrated base-system monorepo that contains the kernel, the system libraries, and the low-level userland services and software. Rather than teams working on one component that has a contractual ABI with other components, there are no real "team-shear-layer" ABIs, except at the public API level that gets presented to users; and instead, anywhere below the userland public API level, is free to be modified as part of the project of modifying system software. (Think, by analogy, the introduction of pledge(3) in OpenBSD. Apple can insert new "technologies" like that throughout every layer of the system very easily—and they often do!)
- Darwin is installed and tested like a BSD: it's a whole base-system release, containing an inseparable kernel + base system. There is no way to test individual components in isolation (without a complete mock of the rest of the base system), as the components may all have circular dependencies — the kernel can depend on the base system just as the base system can depend on the kernel, because it's all one "layer." There's no package manager; no packaging; no components with separate build artifacts that get "integrated." You just build an entire base system, and have to wholesale swap your old base-system for the new one. (In the "old days" on minicomputers, the rootfs wasn't BSD per se, but was specific to booting that machine; while /usr was a BSD on tape, direct from Berkeley. An "OS upgrade" of a BSD was a new /usr tape for you to mount on next reboot. These days, macOS uses APFS system volumes to achieve almost exactly the same thing.)
AFAIK, there's no real good name for these properties besides "a BSD" — despite these properties not really being BSD-specific. Maybe let's call this "BSD-style OS architecture"?
macOS before OSX already had BSD-style OS architecture — though it was something closer to embedded OS architecture at first, shipping OS-on-ROM in early Macs, and only evolving toward updateable on-disk kernels with System 7-or-so. But the Apple development team's BSD-style "thinking", is what made the choice of merging macOS with the Jobs' NeXT Darwin BSD base-system, an "intuitive" operation, rather than something fraught with paradigm-conflict. It's the same reason that Apple ran NetBSD on the servers they ran to back WebObjects for iTMS, back when: "BSD-style" is how Apple engineers think.
it really isn't