You are comparing the time a technology was supported with the time it was announced a technology would no longer be supported. 32-bit apps were supported in 64-bit Mac OS systems for at least 7 years.
Almost immediately after 64-bit support was added in 2005, it was the recommended path, not only for new apps but for existing ones to migrate to. For example, an document called "64-bit Transition Guide for Cocoa" [1] was first published in 2007. A few years later, another document [2] was more explicit:
> Should You Recompile Your Software as a 64-Bit Executable?
> As a general rule, in OS X v10.7 and later, the answer is probably yes.
OS X 10.7 was released in 2011.
Certainly, many – most – app makers did update their old apps. For example, Apple's refusal to support Carbon on 64-bit famously forced Adobe to scramble to update their apps to run on Cocoa, because they considered 64-bit support to be essential. Admittedly, one of the chief benefits of 64-bit was the ability to address more than 4GB of memory, and pro apps needed that more than your average app. But your average app was also easier to recompile, so in practice, pro apps were if anything the slowest to migrate. Even then, most of them did, long before the official deprecation.
By the time the deprecation was announced, let alone by the time Catalina was released, most apps that were still 32-bit were the ones that had ceased to receive updates altogether. From that perspective, the exact timing of the deprecation doesn't matter that much: most unmaintained apps aren't going to become maintained again because of an announcement by Apple. It was going to hurt no matter what.
[1] https://developer.apple.com/library/archive/documentation/Co...
[2] https://developer.apple.com/library/archive/documentation/Da...
Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what.
Well, here are the Steam Hardware Survey results from some random date in 2014:
http://web.archive.org/web/20140318083854/https://store.stea...
If you click on "Windows Version", you can see that a substantial percentage (~20%) were running 32-bit versions of Windows, which can't run 64-bit applications. Most of those were likely on 64-bit processors, but had 32-bit Windows installed anyway for whatever reason; IIRC that might include driver support and not needing as much RAM. So game developers were forced to ship 32-bit binaries if they wanted to target those users. (They could ship both 32-bit and 64-bit versions, but that's relatively difficult on Windows; there's no equivalent of Mac "fat binaries". And there wasn't much point.)
That's Windows, not macOS. But then as now, game developers targeting PC primarily cared about Windows, with macOS as an afterthought at best. If the Windows version was built as 32-bit, the macOS version likely would be too for simplicity's sake.
There's also game consoles to consider. PlayStation and Xbox both switched to 64-bit in 2013, so most games released from then on would have to at least have 64-bit-clean codebases (even if they weren't tested specifically on 64-bit PCs). But earlier games might well not be 64-bit clean; the kind of low-level hacks that make porting to 64-bit difficult are probably more common in game codebases than your average app.
Were there? On iOS, I lost access to a lot of games due to the 32 to 64 transition. On Mac OS, nothing I used was impacted. If your app wasn't 64 bit, it was abandonware. Even the abandonware that I actually use, like Gitbox, was already 64 bit.
Yes, lots! I won't go through all the individual 32 bit apps I use because it's idiosyncratic, but this has been a major complaint about Catalina, aside from the OS's general buggyness.
If you want to switch to 64-bit, you don't introduce machines that cannot do that, that need their 32-bit ABI and have to be supported for years to follow.
1. Either their engineering org is so bad they can't afford to spend some of their massive resources on backwards compatibility.
2. They just don't give a shit.
Either way, not a great look.
1. Wait a few months, Core 2 Duo was on it's way. Previous Nehalem generation did support 64-bit, so obviously, the next Core Duo SKUs with 64-bit support were on the way. This way, they could skip x86 ABI entirely.
It's not like Apple doesn't have long periods without updates of specific models.
2. If they really had to release a model that introduces 32-bit ABI, they could support it properly.
So by doing it the way they did it, I have to agree with Jasper_. The only difference with his conclusion is, that in my opinion they just took the option 2.
But they did take that option and now refuse to pay the price. They are forcing paying the price on their users now.
They got additional benefit at the time, if I remember correctly: Adobe suite was 32-bit + Carbon; so having 32-bit x86 ABI allowed to them and to Adobe to have the suite running natively on the new CPUs, buying Adobe time to port to 64-bit and Cocoa, and axe Carbon without waiting to axe Intel entirely.
Given the benefits they got, they should be called for not wanting to pay the price.
Perhaps you need to be more charitable and try to find the reasons why devs and businesses chose to only support 32-bit.