> Apple breaks existing apps.They have a pretty long beta program (source: Apple dev., since 1986). If your app doesn't work with the upcoming release, it's not Apple's fault.
Some companies will refuse to start testing, until the OS is officially released. That's a corporate process problem, and not Apple's.
I'm not an Apple apologist, though I am often accused of being so (because I develop Apple apps, that is enough to categorize me as a "fanboi"). It's just that Apple (and many, many other companies) goes well out of their way to accommodate prerelease testing of apps on their operating systems, and many many companies don't bother to avail themselves of the opportunity. I do have a problem with people that consider themselves to be "professionals," having these issues, and blaming the operating system, when the fault is PEBCAK.
I tend not to do very much testing of prerelease, beyond a simple "make sure it doesn't crash" test. I will turn up an issue, from time to time, but it's rare. When I do get an issue, it is often that I rely on a certain order of calls, in delegate protocols, and they can change, with OS releases (the fact I rely on the order is a bug, and this just exposes my bug, so I need to fix it).
This is because I take a very conservative approach to writing apps, use native Swift, but not "bleeding edge," and support one version back. I have deprecation warnings turned on, and all warnings as errors, so I can't compile, if I have stuff that Apple sees will break (usually, the deprecation warnings start a couple of major releases in advance).
I also don't use dependencies, or write, using hybrid systems. That helps a lot.