I think one of the sticking points on this idea is not anything technical between ARM64 and x86-64 but rather Apple's recent abysmal track-record in letting particular products get totally out-of-date before replacing them with radical departures, forcing anybody who needs to replace old/broken/stolen/out-of-support/end-of-lease hardware/equip new employees/etc. to become an unwitting early adopter.
See: Mac Pro (last updated in 2013 - suddenly replaced with a far higher-end machine at nearly 2x the price), Mac Mini (2014 cheap laptop-in-a-box replaced with 2018 desktop-class-without-GPU at 1.5x the price), MacBook Pro (nearly 2 years out of date - long for a mainstream product - when the radical late-2016 re-design was launched), MacBook Air... and with the 12" rMB and even the iMac Pro heading that way.
So, understandably, some people here are writing as if their Intel Mac is going to be torn from their grasp overnight. A switch to ARM
would be a disaster if Apple don't keep the Intel option viable for a few years yet.
It depends from application to application, but for applications written in high-level-languages (C/ObjC/Swift etc.) the processor type should be almost irrelevant - whereas changing from iOS to/from MacOS or tvOS could be a big deal that involves re-inventing the user interface and using a different application framework. (That's something that Apple's 'Project Catalyst' promises to make easier - but probably only for existing iOS apps or new MacOS apps).
So in many cases, ARM support
will be just a case of re-compiling (and testing, so never completely trivial) - or maybe making some minor tweaks. Some of the big potential issues - 64 vx 32 vs 8 bit and 'little endian' vs. 'big endian' and the actual number of bits used by some data types don't change between x86-64 and ARM64 and/or when you're still using the same developer tools.
There will, of course, be major exceptions - especially in big, complex packages and double-especially where they've been ported from Windows - where developers have used processor-specific assembly language for speed to utilise processor-specific vector/SIMDs/codec features, but that should be less prevalent today than for the Intel switch in 2005 and
especially the 68k-to-PPC switch in the 90s - not only do we have faster processors and better compilers (so there's less need to use processor-specific code for speed) but modern OSs have high-level frameworks for graphics, vector processing, GPU-based computing etc. that help keep processor-specific code out of Apps.
Certainly, any applications not being actively maintained will go extinct - but that is going to happen
anyway when MacOS Catalina drops 32-bit support - in many cases, supporting ARM will be a similar level of effort to converting to 64 bit. I'd assume that its the big 'pro' packages that do hardcore number-crunching and have legions of obscure third-party add-ins that will be the big stumbling blocks, so the Mac Pro/iMac Pro would logically be the last to go ARM.
To put it slightly trollishly - if you want your computing platform of choice to be held back by a small core of legacy applications that rely on ancient codebases - that's largely what makes Windows what it is (although MS are
trying with Win10).
True - but should supporting the ability to run Windows apps on a Mac be a priority?
While I'm not saying you don't need Windows virtualization
today I think it's a diminishing need in a computing world that has been changed beyond recognition from the totally Windows-centric world of 2005 by the increased use of mobile devices and web technology.
When I substantially switched to Mac as my main machine ~2006, the ability to run Windows was invaluable. In the last year or two I'm finding that I use it less and less (esp. now Affinity designer has arrowheads !
). In the BYOD era, many obscure in-house Windows apps are being replaced with web-based apps, and websites/apps that require Internet Explorer are (thankfully dying out). Where I do use Windows for testing I'm finding it lacking, have found a number of 'red herring' problems that have to do with virtualization, and am probably going to need to get a Windows convertible so I can test things on touchscreens.
