I don't think the legacy x86 code issue is anywhere near as big a hurdle as many people seem to think, because Apple have a weapon there that Microsoft doesn't

I don't think the legacy x86 code issue is anywhere near as big a hurdle as many people seem to think, because Apple have a weapon there that Microsoft doesn't have, and Apple didn't have (at least to anywhere near the same level) during the 68k/PPC and PPC/x86 transitions: Xcode. Just about every native Mac app these days was developed and built on Xcode, and Xcode already supports ARM targets. The only remaining obstacle is porting AppKit to ARM, and if (as the original story suggests) Apple already have hardware running OSX-on-ARM, they must have already done that. That means most Mac apps can be ported from x86 to ARM with little more effort than changing the target in a dropdown list and hitting Build. (For those not familiar with Mac development: AppKit is the GUI library, part of Cocoa, used in most modern Mac apps. iOS apps use a slightly different GUI library, UIKit. At the moment AppKit only targets x86/x64 and UIKit only targets ARM, at least in the officially released versions.) Microsoft can do something similar with .NET, as others have pointed out, but .NET apps don't dominate the Windows software ecosystem to anywhere near the same extent that Xcode+Cocoa dominates the Mac one. (One thing I'm quite certain we're not going to see is the hypothetical dual-CPU ARM+x86 machine that some people are speculating about. For the simple reason that, if you're going to put an x86 in the box anyway, why bother with an ARM as well?)