How is that different from your code not working because of an Apple bug (which they take months or years to solve in some cases)?
The end result is still a broken app (just due to a different reason), and the user will blame either the third party programmer or Apple, and mostly usually the programmer.
Part of the reason why it's hard to fix bugs that people have worked around is because the fix often breaks the workarounds. Which causes a problem for Apple either way; either they can leave the bug in and let everyone work around it, or they can fix the bug and break all of the myriad apps that use the workaround. Depending on the circumstances, they can actually put workarounds into the frameworks to preserve bugs for apps linked against older versions of the SDK or for apps with specific bundle IDs, but not every fix is amenable to that kind of solution.
Which is to say, there's a good argument for the idea that reducing the ability to monkey-patch framework classes will make it much easier to actually fix bugs in the frameworks.
>Part of the reason why it's hard to fix bugs that people have worked around is because the fix often breaks the workarounds.
That was a problem for Microsoft, Apple, from all we publicly know from their releases, never treated that as a problem. They went ahead with the fixes even if it broke previous workarounds.
If an OS upgrade breaks lots of programs or even one heavily used program, chances are users will blame Apple, not the developers of said apps.
Also, part of the reason that it takes them long to fix certain bugs may be concerns about seemingly internal changes breaking applications. They cannot refactor methods (rename or even change an argument list) in any class they ship because someone, somewhere, might override one of its methods.
In that light, I think the change makes sense. Of course, Apple could just add private/sealed to all their classes, if only just before shipping, but why make the typical choice more work to write than the exception?
>If an OS upgrade breaks lots of programs or even one heavily used program, chances are users will blame Apple, not the developers of said apps.
The user just knows said program doesn't work. And it's not necessary that an OS upgrade will break lots of programs that a user has, it can break this or that program in subtle ways, or classes of programs (e.g. those using the X api) of which a typical user will have only few installed.
E.g. if it breaks third-party camera apps, users might not normally have 5 of those, to see that they all break at the same time, but just 1 additional on top of Apple's (if that).
The user knows the program worked yesterday, before (s)he upgraded the OS. Correlation is not causation, but I think you will get more hits googling "<OS> update breaks <application name>" than googling "<OS> update uncovers bugs in <application name>" for whatever currently used choices you pick for "<OS>" and "<application name>".
Users don't always use all of their apps apps every day. If you go to the app 20 days after updating the OS, good luck remembering the OS update 3 weeks ago and deducing it was that which broke it.
Especially since, with the ability for apps to upgrade automatically, many don't even keep track when this or that app was updated.
Of course it usually is even more obscure, e.g. the bug only affects PART of the app's functionality, a part which you might have not invoked in your last run before the OS update. So, another deduction for many would be that that feature works intermittently because it's not coded well, etc.
Besides, even when the user can deduce that the OS broke the app, they don't complain to Apple, but to the software maker "fix your app", "where's the update release?", etc.
You missed the obvious fact that the bug change might happen to an API you already use. It doesn't have to be a new API -- just a new release of it by Apple.
So the problem remains: you can't easily extend the class with your own fix to bring out a bugfix release for your app.
The end result is still a broken app (just due to a different reason), and the user will blame either the third party programmer or Apple, and mostly usually the programmer.