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