They could simply decouple the apps from the OS, like Android. Safari and Mail.app do not need to be tied to OS releases.

Android OS releases do not get nearly as much fanfare because a lot of core functionality is decoupled from the OS: app store(s), mail clients, browsers, todo lists, even the text messaging apps and some security frameworks.

Which of course is exactly why Apple keeps everything in one big release. They want lots of press talking about the brand new features.

I wonder if there's some anti-trust consideration to it. If Apple were able to update all their apps separately from the OS that would mean they had accessible APIs to do it. People would complain a lot more loudly about Apple blocking replacement functionality and Apple wouldn't want to allow a replacement for, eg, the messages app.

If you integrate the apps directly into the OS then you can just say that no APIs exist, those are just features of the operating system itself.

I think you're right about the decoupling. But I don't think they do it this way for press reasons to be honest. Apple is all about integration, And it makes sense that this applies to Apps/OS as it does to OS/Hardware. Also, most buzz is generated by OS level changes (Dark mode etc.).

Safari can actually be updated separate from the OS.

Apple operating systems are on a semantic versioning system with regards to API. The idea is that API only break on the major version update which is released each year (ignoring that a the OS X version has a "10" in front of it).

Non-breaking API additions and userspace features which do not impact API can be rolled out throughout the year though. There are also changes to private API throughout the year since the Apple apps using them are distributed with that operating system release.

Generally, API grow up as private API that get adopted by other Apple apps, then may get promoted to public once they are stable and maintainable.

IMHO, the big issue with iOS 13 and Catalina this year was that there were several huge developer features and internal system refactoring which were maturing during beta. This slows down everyone who is dependent upon those features. The solution there is to require public API to have a higher level of maturity before that beta 1 release.

I disagree that Apple is waterfall, because their release dates are fixed, and they will change what will be delivered to make that date. I don't know if a twice annual major feature releases (and corresponding WWDC summer and WWDC winter) fixes anything, or if it just makes the life of third party developers harder.

Microsoft tried doing that with the bi-yearly Windows 10 feature updates, and now they are moving to a yearly release cycle because there were too many bugs getting into releases even with an army of "insiders" (although it should be an army of QA people that are in Redmond). They don't release major updates to system applications between releases either (The rewrite of Edge and WSL2 are planned for release 20H1).

The real problem is that Apple needs to loosen the secrecy between engineering teams, as there's no good way to tell if your new Safari feature breaks something in System Preferences because the System Preferences developers are in another building and aren't under the right NDA to learn about your new Safari feature.

I think we should not conflate SDL and long term product and feature planning. You can have both agile SDL and long term planning.

"Agile" is only about software and it doesn't always work even for tiny projects. Apple's products are so much more than this. Distribution, marketing, manufacturing, support etc.

You can't delay a new iPhone release because it's imperfect. They make phones to make money, and they are very good at it.

Cf with Microsoft I think they are ok. Past mart just cannot upgrade. Now is so much I have to take a rest and avoid the upgrade.