Much depends on whether the processor change is also used as an excuse for other platform changes. Imagine, for example, locked down firmware that can only boot Microsoft software. The ARM processor itself is not to blame but may be enough of a break with the status quo that they may feel emboldened to make more strict lockdowns.

ARM might become a tricky platform, depending on how nVidia's acquisition attempt goes and their plans on how to manage it. For example, the very next release of cumulus after nVidia purchased it supported only nVidia switches (that they had separately bought from Mellanox).

The fact that Mac moving to x86 was a good thing was due to a few factors:
-IBM sucked at competing with Intel/AMD on desktop/laptop use cases, so it was good to move over.
-Mac could then run Windows natively
-The 'hackintosh' concept opened interesting possibilities, though in practice they just end up fighting Apple

Going to ARM makes people hopeful that more players could participate, In addition to Apple and Qualcomm, nVidia, and Marvell seem like likely companies to bring out an offering if the market is viable, and Intel and AMD may be able to participate should the day come that ARM software is preferred.

What's old is new again. Back in ye olden days when I first got into computing, you had multiple platforms, some adhering to basic POSIX standards, some that were way out there. It took some effort by developers to build suitably cross-platform and cross-architecture code. But it certainly was done, and done a lot. I worked on both Xenix and Linux systems in the early 1990s, and by and large the basic libraries were similar enough that the most I had to do was just make the right Makefile flags were set.

As it is, even when OSs use the same architecture, the OSs can be sufficiently different that you're either going to have to recompile or install some sort of compatibility layer or virtualization if you well and truly want to have universal binaries. But a lot of code these days is written in languages like Python and Java, so, like Bash, Perl and sed scripts of the long ago time, you could often get quite a bit of production code working with very little effort.

Frankly I think it's good that the x86/64 world has some growing competition, and if it means we go back a bit in time for developers in having to pull their socks up and learn the tools that previous generations of coders used to get their software to compile on different machines, then so be it.

Diversity is an awful thing in almost that is foundational. The reason why desktop software is so easy to make today is because you only need to target one OS and one CPU instruction set to hit overwhelming majority of the market. Today, that's Windows/x64.

The more instruction sets and OS's you have to target, the less development resources are left for developing actual software to do what it's supposed to do. Because in real world (as opposed to utopian visions so popular today) resources are highly limited. Remember Itanium? There's a reason why we use AMD64 instruction set, even in intel machines today. Because unlike Itanium, AMD64 instruction set was fully backwards compatible with intel's x86. The unified de facto instruction set for desktop computers.

You do not want diversity in your baseline elements of functionality. You want high level of unification. Because that allows you not to worry about all the diverse problems that come with diverse baseline. You don't want a car market where every car has a completely different way of driving it from all other cars. You don't want a lot of shops each of which accepts only its own kind of payment system. Diversity is a very, very bad thing in core functionality. You want the opposite of diversity there, you want high levels of unification. You want cars that all have steering wheels, an accelerator pedal and a brake pedal, so that when you know how to drive one, you know how to drive all. You want all shops to accept same paper money and credit cards/etc payment methods that can be read in a single reader, so you don't need to carry a separate card and separate currency for each shop you plan to patronize on that day.

Highly unified baseline functionality means that you can actually build diverse products on top of it, because you don't need to commit massive amount of resources just to make sure that baseline works.

Performance and compiler tools have improved to the point you can put everything on top of a couple layers of hardware abstraction and not make the system completely unusable. You could see this emerging with Android where you had Intel, MIPS and ARM architectures running, if not perfectly synchronized performance-wise, at least close enough to be useable for most tasks.

It was a no-brainer for Apple, who had switched their toolchain over to LLVM/Clang/Swift years ago, which natively supports ARM and X86. Unless you are doing something weird, recompiling from X86 to ARM using Clang for MacOS involves changing a compiler switch.