<i>Nobody wanted to pay more for cores with no software support.</i>

This is just the general backwardness of many of the SOC providers. ARMv8 has a 32-bit compatibility mode (aarch32) designed to run 32-bit software. So any core produced would have run any of the existing android/etc OS's and applications just fine with a path forward to 64-bit. Since all the major players had their own core teams they could have been tasked with making armv8 cores, but instead were doing the minimum required. Its only after they got broadsided by apple did they scramble to license ARM's cortex designs since they didn't have any of their own.

edit: Just to add to this, despite the article, ARM was doing just fine in the smartphone market selling a 32-bit architecture against mips & x86 which had a 64-bit architectures. The articles comments about the additional registers fail to note that 32-bit arm had a pretty generous register layout (16 GPRs) and wasn't at all register starved in relation to something like 32-bit x86. Similarly with NEON/etc. QC/etc were right that 64-bit didn't bring much to the smartphone market at that time except for a path forward. To this day there are a lot of applications that fail to gain any benefit from going to 32-bit which is why x32 and the arm64 ilp32 ABI exist.

> ARMv8 has a 32-bit compatibility mode (aarch32) designed to run 32-bit software.

It did until Apple dropped it ¯\_(ツ)_/¯

The danger is releasing a more expensive chip that is no faster at running existing 32-bit code and having no phone manufacturers opt to use it.

But this isn't really how it works. The chips were getting faster, so you just do it along with the planned uplift changes. Most people didn't buy Athlon64s because they were 64-bit (except for us computer geeks) they bought them because they were the next evolution of a better processor than the competition at the time.

That was fine and dandy in the early-2000's when Moore's Law was still in full swing. Chip makers aren't practically guaranteed a compelling speed and efficiency boost just because a year or two have passed since the last gen, where it was a no-brainer to toss in 64 bitness since process improvements would gloss over any deficiencies or regressions.

Why to have extra functionality for more $ when you can use just standard one? They are counting cents on those chips, margins are horrible...

Because, tech industry business 101: If your not moving forward your getting left behind. That is unless your colluding with everyone else in the space to slow innovation. The second ARM announced there would be a 64-bit version of their architecture, every single player should have been planning a migration with the knowledge that their competitors probably were.

> aarch32

But aarch32 adds a whopping 0.8 mm^2 to the core! sarcasm

It's not enough to just run existing code. You need new code to run.

It's a chicken and egg problem. No serious gamedev company is going to invest in code that is capable of taking advantage of new stuff when there is not a single one device on the market (and the issues of the first generation known and work-aroundable), and no chipmaker is going to invest into radical modernizations if there is no demand.

And you get that code by giving developers hardware to run it on. Outside of some hardcore early bring-up guys just about no one develops software on models and emulators.