I believe there is a little bit of overhead when it comes to mapping virtual addresses and dealing with different pointer sizes for the OS, but imo the main reason Apple wants to ditch 64 bit support is so their OS isn't tightly coupled to an ISA that has 32/64 bit modes.

In other words it's not about the overhead, it's about the reliance on x86.

If ISA decoupling is the goal then they should be mandating everyone write to a VM like the CLR or JVM (or variants like Dalvik).

It seems kind of silly to block x86 modes on x64 chips when the backwards compatibility needs of Windows pretty much insures "eternal" x86 modes. It's going to be a while before x86 modes disappear on Intel or AMD chips, and there's evidence to support that like the Itanium (IA-64) failure, and the fact that Windows on ARM made it a commitment to emulate x86 (but not x64) on ARM. x86 is likely going to be a lasting "lingua franca" ISA. Right now I'd almost put more money on x64 being retired before x86, and if anything from that perspective Apple is more tightly coupled to an ISA than before this choice.

> ...if anything from that perspective Apple is more tightly coupled to an ISA than before this choice.

That really depends on what their long-term goal is. If the speculation & rumors about an eventual ARM transition have any merit at all, then sunsetting 32-bit support now can help them smooth that transition, since they'll have a lot less work to do to implement whatever Rosetta-esque dynamic binary translator they would need.

Microsoft and Qualcomm together supposedly just invested tons of money in making sure that x86 emulates well on ARM64, but apparently had little success emulating x64 on ARM64. If the speculation and rumors about an ARM transition have merit, it seems backwards to sunset x86 and not x64.

Which it seems unlikely that Apple could do in secrecy what Microsoft + Qualcomm could not do (very publicly), but I guess all things are possible.