With audio hardware it’s looking like substantial rewrites to core code because of underlying is changes. I think it’s just a lot of work on a short timeline for small development shops.
I mean most software that's currently maintained has been 64-bit ready for a decade. The issue is that there's a lot of 3rd party ghostware that isn't, and 32 bit bridging to support that code has been popular for awhile.
That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.
Sounds like the software was effectively already dead and it was best to move off it as soon as it became clear there was only one developer and they were hard to get hold of. The problem isn't with macOS.
I would note Chris, given your insistence on all this, that your own project Graal is still shipping on Java 8 despite that being many years old. You're now working on moving to Java 11, which is itself already obsolete.
Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
Sure, but so is Mojave. It'll be some years before Apple stops shipping security updates to older releases. Until then app vendors saying "don't upgrade macOS" is no different to Java developers saying "don't run this on Java 11 because it doesn't work yet" and we've seen plenty of that.
In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.
Your software doesn't run in isolation. It needs services of the operating system. Apple has to spend resources maintaining 32-bit software and consumers would rather they didn't do that.
Going to 64 bit can be a lot of work. So there is quite some software which is still lightly maintained for which there isn't a 64 bit update available. Software which has worked perfectly fine up to date.
Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
If a program works fine, with no issues, why should companies be forced to update it simply because Apple decrees they no longer support 32 bit applications? "Sweeping the dust" is an absurd declaration.
I think sidecar uses h265 so it's probably a question of the GPU either having dedicated h265 hardware or having enough grunt to run some kind of shader.
It's not just 64-bit though. There are also some fake-security "notarization" requirements that were notoriously vague and poorly documented for months, as well as some equally vague and unspecific threats that certain non-notarized applications might or might not cease to work on January 2020. I've been developing for Macs since the late 90s and have never seen less clear developer info.
Thankfully I'm not in that position, but many companies can barely keep up with their day to day stuff. There is never time for doing something for the distant (or not so distant) future.
