Even with the so-called "public" APIs, the way Apple operates, there is no guarantee of any stability, as most iOS developers know. AppKit is much more stable than UIKit, but still nowhere near the stability that companies like Microsoft provide (including changing the name of a product—Windows 9->10—so that existing software does not break!).

If you are using features of the frameworks that are outside of the "happy path" for that year's keynote announcements, you can expect terrible bugs on a yearly basis. These bugs happen for the exact same reasons as stated in the GP.

Can you give some examples of those "terrible bugs" you have experienced on a yearly basis?

I have developed for iOS for the last 5 years, and I haven't ever experienced those in UIKit. This year brought one single bug in UISegmentedControl, in a situation that doesn't happen often: https://forums.developer.apple.com/thread/122736

UINavigationController—https://twitter.com/LeoNatan/status/1168286477882728448

UITabBarController—https://twitter.com/LeoNatan/status/1168286996915204097

UIActivityViewController

Various UIView layout issues

Safe areas—https://twitter.com/LeoNatan/status/1179475940784721920

UITableViewController—iOS 13's sheet presentation broke clearsSelectionOnViewWillAppear (https://twitter.com/LeoNatan/status/1137474148488364034), for example, but it's often broken: https://twitter.com/Javi/status/644631570083483648

SLComposeServiceViewController is completely broken on iOS 13

You quoted a bug in 2015, then three in 2019. That's not on a yearly basis. Aren't your views colored by a bad iOS 13 launch? Because I do agree with you that iOS 13 seems bad (not my personal experience, from the general clamoring around us).

No. I maintain a pretty popular iOS open source project, as well as many low level projects for my job. It’s always unstable. Every year, new bugs pop up. Is it the end of the world? Probably not, but is it acceptable? It shouldn’t be. Before 10.15, I could run Mac software built 15 years ago. If AppKit developers can preserve backwards compatibility, so should UIKit developers.

But doesn't that go for anything? Take android where you need to account not only for all the cases of versions but also for every differentiated version from every brand and device, or if you build for things like silverlight which gets killed with no replacement. There are always things changing and unless you are on the same path as the vendor you're gonna get screwed. It's always been like that.

If a proprietary software is not much more better than an open source one, I will not choose it.

I think you misunderstand what I mean. There is an API, which is documented to function in some way. You'd expect it to continue functioning like that down the road, but since Apple engineering has such poor QA and is always rewriting things, their developers just let things slip through the cracks, often creating broken API for years. Android whataboutism is not really productive here.

Odd. I never had a public API go bad on macOS, ever. There were always multi-year planned deprecations etc but no sudden changes. The only issue I remember had to do with a toolbox issue before my time where timing wasn't always reliable to be sub-ms precise. Even 68k to PPC transition went fine API-wise, as well as toolbox to carbon.

Perhaps you are exclusively referring to mobile 'apps' and the APIs you can use for those?

Yeah, the context of the post you replied to is for iOS APIs. AppKit is a lot more stable, and it shows. It is still possible to run 10-12 year old software on Mojave (but not on Catalina). On the other hand, sometimes even one OS upgrade can break existing software visually or worse on iOS.