Most of the new app features are tied to OS-wide and OS-APIs wide capabilities, so they can't release "just Notes" without the OS-level frameworks that support those features. Take for example the PDF editing/support in Notes now. Or the Pages compatibility. Or Note widgets for the desktop, etc. Similar case for Safari, as they offer the webkit widget and JSCore as an OS-level APIs too.

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

I give you that some of the new features are tied to OS-wide updates, but many of them seems they're not. And if they wanted to, they could still decouple apps from OS updates and if you're on a old OS version and the new app update requires a newer OS, just block that specific update from happening.

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

Safari 17 is also available on Monterey (macOS 12) or Ventura (macOS 13).

No need for a testing matrix (Does version X of app work with version Y of MacOS)?

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

This method reduces testing burden by eliminating the combination of an old OS with new app.

They might also see it as an incentive - perhaps new app features act as driver for OS adoption.

On the flip side, zero-day WebKit security vulnerabilities require a full OS update to patch Safari.

From a security perspective decoupling from OS updates seems advantageous.

RSRs [1] are sort of not this though. They’re still a bit weird, but can contain updates for WebKit and/or Safari in a very small update that installs very quickly. Also worth noting that WebKit is buried pretty deep in macOS (as it underpins a lot more than just Safari) so isn’t as easy to patch by itself.

[1] https://support.apple.com/en-mk/guide/deployment/dep93ff7ea7...

macOS is a BSD; the whole point of BSDs is that the OS and "base system" are vertically integrated (and, usually, living in a monorepo together) so that a dev can one day decide to add a new API to replace one currently used by first-party apps, by just adding the code and then doing a big Search+Replace to fix all first-party apps to use it, all in a single commit.

The user land is from FreeBSD. It is not “a BSD” otherwise but this myth still gets repeated constantly.

macOS is a BSD in the same way that Linux is a Unix.

i.e. they may have started out that way, but almost nothing is gained thinking about this history today, despite it being factually correct.

What I mean is that:

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

>macOS is a BSD

it really isn't

A lot of the app updates are using new APIs that only exist starting with the OS update. Practical way to surface the new OS features.

I have a company-provided mac, I don't have an App Store account as it requires a phone number (and I'm not going to use my personal phone number to register it, it is not even allowed by policy) so I'm not going to update any app via the store

Well, then this doesn't really affect you as you don't have a choice regarding updates at all :)

Your company could use Apple Business Manager/Managed Apple ID if they wanted to.

Apple knows that you want the app updates. They want you to update to the latest OS for a variety of reasons (support, security, marketing, etc). They also know you paid thousands of dollars for your laptop and aren't likely to switch off of macOS entirely. So, they bundle the app updates to the OS update as an incentive.

Cause then no one would update?

I'm not sure why Notes needs to be bundled with the OS update, but Safari isn't. You can download Safari 17 for macOS Ventura as well! Only the features that require integration with other apps (such as auto-filling 2FA codes from Mail) require Sonoma.

The fact that Safari is available for multiple OS versions might be a remnant of the work done to ship Safari for Windows.

I reckon it's more likely that Safari as a browser represents a more important set of security holes and therefore Apple feels greater obligation to patch patch problems (and that's easier to do by simply shipping the whole app rather than patches for old versions).

This is exactly it - as long as they support macOS for X years they need to release safari updates for that long, so they might as well decouple that one.