Yes, the documentation is scanty in places, and there is some missing functionality at the moment. And the support burden on these companies, once 10.15.4 ships, will be a pain ("It's OK, the software still works, don't worry about that alert message"). But it is incorrect to say that Apple has not given developers time to react.
I'm treading extremely old ground, but fwiw:
I don't fault Apple for pulling 64 bit Carbon from Leopard. It makes sense—the OS had already been delayed and they had to cut stuff in order to ship.
But I find it totally bizarre that they never shipped 64 bit Carbon. Why wasn't it in Snow Leopard? Heck, Lion even.
Catalina's nixing of 32 bit would be a lot less painful if Carbon apps had some kind of upgrade path.
I don't. Carbon was a >20-year-old codebase which had always ran on a 32-bit system. I wouldn't be surprised at all if they simply determined that there was too much code which would have to be rewritten to run correctly on 64-bit.
20 years is nothing (/grabs your lips and makes them say "NSObject"). Don't talk to me about code quality either, just because something is old doesn't mean it's bad (or good) it just means it's old.
This is especially true for "the last 20 years" in particular (that featured elimination of most American tech workers with more than 20 years experience during the dot-com crash followed by a six year timeout where upon most American universities did not graduate many CS majors and those that did had no real "industry mentoring", just Google searches and blog sites.) IN MOST CASES, THE QUALITY OF THE OLD CODE FROM BEFORE THAT ERA IS GOING TO BE FAR SUPERIOR TO THE CODE PRODUCED DURING THAT PERIOD.
Things are just now (14 years after the new CS majors began to arrive at their desks) starting..and I do mean starting..to get back to normal (the people who infested the industry in the absence of such formally trained talent are still around, many have whipped investors into FOMO, allowing them to live very well and thus be influential and even exploitative of the younger formally trained CS majors, instead of the other way around).
Certainly but the problem is that such changes should be announced years in advance.
Cocoa, OpenGL, ObjC... all are going to die some day and Apple will probably announce it 1 year before it happens, at the most.
Unless you’re suggesting that Apple will only give 1 year’s notice when they remove deprecated features - in which case, they might only give 0.25 years (at WWDC), which happens quite frequently.
Directly jumping on the provided alternative is basically doing beta testing for Apple. Very often the alternative is not ready yet. For years after it was announced Swift was not production ready. SwiftUI will probably replace Cocoa but again it is not production ready yet (and doesn't work on the majority of Macs).
What if there is no alternative? There are many crossplatform projects that rely on OpenGL and moving to Metal is problematic since it's an Apple only API. No replacement for Carbon either because at some point Apple decided to abandon the port to 64 bits.
How much time should one wait before fully jumping, say, into Swift? Nobody knows. Apple could announce today that it plans to kill ObjC by 2025 and give devs a good picture of what it's going to happen and its commitment to X feature. I suspect the problem is that not even Apple knows when it will finally decide to do that.
There is a lot of uncertainty. How can one decide to start a new macOS project today without knowing how long that investment will last? For example if you invested heavily in OpenCL a couple of years now you'd have to rewrite all that code to Metal. Or moving from ObjC to Swift. Or moving from OpenGL to Metal. Etc. This is a luxury that not everyone can afford and Apple doesn't seem to care.
No wonder Apple is the only big developer working on macOS exclusive products and they are trying to bring over iOS devs via Catalyst.
Each WWDC thereafter, either test your deprecated code for surprise breakage on the new betas (this happens), or remove your deprecated code if the betas remove support for it.
If you aren’t committed to reviewing, testing, and updating your codebase annually (or shutting down products that are no longer a good fit, like iDefrag) then you should probably not develop for Apple platforms.
If you’re concerned that there’s not enough revenue to support this every year, then you should reevaluate your position on subscription revenue models or accept that you’ll operate at a loss re: keeping your platform up-to-date.
They could remove Perl/Python/Ruby this year, having only deprecated them last year. Historically they're not inclined to do so, but I'd expect those to be left deprecated until some event permitted their removal to be more convenient (like "new architecture added", which would force a global recompile, at which point lots of deprecated things can go away more smoothly — OpenSSL, OpenGL, P/P/R, etc.)
Also, why half a year? Do you think it will take them that much to release 10.15.4?
I'm joking but documentation (and tech support) do seem to be dying things at Apple and elsewhere.
Fully agree on the documentation point, though.
And to do that, you have to start much earlier.
How is that enough time?
> In macOS 10.15.4, use of deprecated KPIs triggers a notification to the user that the software includes a deprecated API and asks the user to contact the developer for alternatives.