Surely you should only be testing against major releases: that is, only the most-recent point release for each major release. So, for example, Big Sur is at 11.

Surely you should only be testing against major releases: that is, only the most-recent point release for each major release. So, for example, Big Sur is at 11.1, so test against 11.1 but not 11.0. No user should be running 11.0 any more, as it has unpatched exploits. Similarly, every Catalina machine should be running 10.15.7 + the Supplemental Update from a couple of days ago, and every Mojave machine 10.14.6 + the relevant security updates. Now, users or administrators may have valid reasons to sit on a point release for a few days, for example to schedule it when it's less disruptive, or to wait to see whether there it has caused problems as a recent Mojave one did. (But not for much longer, because the act of releasing an update gives black hats something to look at, and Apple themselves usually publish details of the exploits a couple of days after the release that closes them, to give people time to update.) The thing is, they are also not going to install your new software in that window either; almost the only people running your software on other than the latest point release are people who already installed an older version of it, that you tested when that point release was current. Most normal people will either let your app and the OS auto-update on their own schedule, or manually update both at the same time. This all reduces the problem to having available copies of the last few major versions. You can't go back all that many versions because Apple's Xcode development suite stops supporting them, and you don't want to because the APIs change. It's a very different philosophy from the Windows "test against everything", but it's self-consistent, and is not unique to Apple operating systems.