Apple may initially have intended Carbon as temporary, but has changed their stance when they started adding new APIs that never existed in MacOS 9 - HIView/HIWindow was intended to unify Carbon and Cocoa, there was even a 64 buy version of Carbon that shipped in Mac OS betas, and when Retina-Display Hardware shipped, Carbon received new APIs to deal with that.

Likewise, Cocoa in 10.0 was buggy and incomplete. It took until about 10.4, 10.5 for Cocoa to reach feature parity with Carbon and many Cocoa applications were using Carbon for certain features (in facts, last time I checked, Cocoa menus were implemented in Carbon).

HIView and HIWindow were added, if I recall correctly, because it allowed other toolkits (tk, Qt (who only recently moved off this), etc) to draw the native look “properly”. It was never actually up to date or well documented, and they kept it around just so the OS didn’t look so totally bizarre as you moved through it (like you see on Windows).

Bolting on Retina support to that is such a no-brainer that I hesitate to call it adding features - that was table stakes in making sure the switch to retina didn’t look like total ass.

None of this stuff ever changed how Carbon was deprecated. People just sat around not listening to Apple, and then the last two years the bigger GUI toolkits finally did the work to transition properly.

HIView was up to date and documented, and there were WWDC sessions teaching developers why they should move to HIView and how to do it. Likewise, Apple provided documentation about how to port your Carbon application to 64 bit Carbon. Maxon reportedly even had a 64bit Carbon version of Cinema 4D ready to ship when Apple suddenly announced that they would abandon 64bit Carbon - telling developers to disregard the 64bit Carbon they were still shipping in betas.

Yeah, no, this really wasn't the case.

Toolkits that used HIView/HIWindow looked very out of date compared to proper Cocoa implementations (Qt, contrary to popular belief, wasn't really "native" for the longest time since they did this - it's part of why it always looked off).

There are very valid reasons to be frustrated with Apple, but the writing has been on the wall for this stuff for years now. Nobody should be complaining at this point.

Exactly. In the days of WWDC 2003/2004 there were numerous separate Cocoa/Carbon sessions, and the Carbon message was to go fully to HIToolbox and Carbon Events.

Carbon NIBs even existed, although the format (XML) and concept (definitely not “freeze-dried objects”) were totally different from anything Cocoa. Xcode 4 and up couldn’t edit or view Carbon NIBs, which made that tech deprecation pretty clear.

> deprecation of semi-official Mac OS ports without equivalents on brew

Apple doesn’t deprecate ports, since they don’t run it.

In other saner platforms (Win32 or even X11, if you ignore Gtk and Qt) you can pretty much assume that if something is deprecated it will still remain around even if it wont get updates as doing otherwise will break all the applications that rely on that tech that people bought and rely on. Especially when that deprecated something is still used by developers despite it being deprecated.

But apparently Apple doesn't care about their users and developers.

Saying "told you so" doesn't help much, the only thing that helps is keeping things working. Anything else doesn't matter.

Though if there is anything that can be "told you so"'d that would be bothering with Apple's platforms when Apple doesn't care about you.

> X11, if you ignore Gtk and Qt

You don't need to ignore those. GTK+2 was released ~17 years ago and Qt4 was ~12 years ago. Apps written with them still run perfectly fine on modern Linux distros.

Qt4 applications will run perfectly fine on modern Linux distros assuming these distros have Qt4 available (let alone installed since Qt isn't as common as Gtk to be considered something you can rely on being installed on any desktop installation). Qt4 is dead from its developers perspective and because of that it will be removed, like Qt3, Qt2 and Qt1 before it. Debian, Arch Linux and others have plans underway to do that. After that is done, Qt4 applications will not work unless the user decides to manually install it (which most likely will imply compiling from source - and good luck solving any incompatibilities between Qt's massive codebase and any of its numerous dependencies - after all it isn't just Qt that breaks backward compatibility, some of its dependencies can and will break it too).

Same with Gtk+2. Once Gtk+2 itself is removed - like Gtk+1 and Qt4 before it - from the repositories, Gtk+2 applications will also stop working. Similar case with Gtk+3 now that the Gtk developers are working on a yet another incompatible major version, Gtk+4.

Also keep in mind that even though the major versions of Gtk+2 and Qt4 were released years ago, applications are still being written and released using those versions (e.g. Lazarus applications to this day are released with Gtk+2 as the Gtk+2 backend is by far the most stable - the Gtk+3 backend is still in alpha state, due to the low manpower that the project has - note that this manpower wouldn't need to be wasted if Gtk+3 was backwards compatible with Gtk+2 and instead all that time would be spent in stabilizing and improving Lazarus, which shows how much developer time is wasted when libraries many others rely on break backwards compatibility).

Now sometimes someone will suggest that applications should bundle their dependencies with them, but this introduces other problems - like the bundled libraries not using any features or fixes or having configuration mismatches with the libraries already installed on the system. This is a worse situation since instead of potentially addressing forward compatibility (you wont know for sure if the developers of the systems you rely on wont promise to not break your application) you are breaking current compatibility.

It sounds like you are just airing your general grievances about Gtk2 and Qt4. The fact is, you claimed X11 with Gtk/Qt wasn't "sane", because sane platforms like win32 "will still remain around even if it wont get updates as doing otherwise". Gtk2 and Qt4 are still around and up-to-date packages are available for all major distros.

And your last paragraph sounds like you don't really know what you want. Do you want old applications to run exactly as is (which is solved by bundled dependencies), or do you want their developers to update them forever for decades and decades (which is solved by abandoning old toolkits)?

Finally, none of this even touches the fact that your "sane" win32 platform has incompatibilities too and there are many, many old win32 apps that doesn't run in modern versions of Windows.

> The fact is, you claimed X11 with Gtk/Qt wasn't "sane", because sane platforms like win32 "will still remain around even if it wont get updates as doing otherwise".

"...as doing otherwise will break all the applications that rely on that tech that people bought and rely on". Do not remove the important bit.

Also i wasn't only referring to Win32 as Win32 does get updates, though they are minimal.

> Gtk2 and Qt4 are still around and up-to-date packages are available for all major distros.

For now. But as i already wrote several distros like Debian (and thus any that depend on it) and Arch are planning on removing it (just like they did Qt3, Qt2, etc). I already wrote that, why are you responding as if i didn't already addressed the issue here?

> And your last paragraph sounds like you don't really know what you want. Do you want old applications to run exactly as is (which is solved by bundled dependencies), or do you want their developers to update them forever for decades and decades (which is solved by abandoning old toolkits)?

It only sounds like i don't know what i want because you see only "which is solved by bundled dependencies" and "which is solved by abandoning old toolkits" as the only possible solutions. I didn't brought those up because they are the only possible solutions, i brought those up to explain why they are bad solutions (something i'm not going to repeat, i already wrote that).

Another solution, which i have repeated multiple times, is for the libraries to not break backwards compatibility. If the libraries do not break backwards compatibility then you can simply link against them dynamically, rely on them being there and provided by the OS (or at least ask for them and expect the OS to be able to provide them) and you wont need to bundle anything (the library is provided by the OS) nor worry about breakage (the application will keep working because the library wont break).

I mean, it isn't rocket science, it isn't dreamland, it is something already happening in both Windows and Linux to an extent. On Windows is the USER32.DLL et al, on Linux is the C library, libX11, libGL, etc. What i'm saying is to extend this to the libraries that also provide a full UI, not just the lowest levels.

> Finally, none of this even touches the fact that your "sane" win32 platform has incompatibilities too and there are many, many old win32 apps that doesn't run in modern versions of Windows.

Yes, there are incompatibilities but Windows is still trying to be backwards compatible and for the most part it succeeds in doing so. I have a lot of older software that work perfectly fine under Windows 10, either by themselves or via minor tweaks. Any incompatibilities that are the aren't because Windows developers didn't try, it is despite their efforts.

On the other hand incompatibilities with Gtk, Qt and now macOS are there because their developers explicitly and intentionally decided to break their APIs. They do not even try (Qt would have a hard time due to it being a C++ API, but Gtk has no excuse).

Lazarus was also amusing for shipping a Carbon backend for macOS until very recently - and then telling people to just use Qt5 while waiting for a proper Cocoa port.

Yeah AFAIK there is only a single programmer who primarily worked on macOS support and he had to work on both the Carbon and Cocoa backends.