aren't the A series ARM chips? Windows has had quite a bit of difficulty getting regular desktop stuff to work on ARM (x86 emulation is slow)
That MS has a working x86 compatibility layer makes me think that Apple could well have something like this too. If the new chips have performance comparable with Intel's, even a 5x performance hit for "legacy" apps might not be catastrophal, since developers in the Apple ecosystem are usually fast to update their stuff and cater to the demands of the early adopters with lots of money.
Apple has gone the emulation route with the PPC/x86 transition before. With their tight grip on the ecosystem, including the development tool chain, I think most software will be updated very quickly.
This is quite different from the situation with Windows software, most of which feels like the Devs hate the it, the platform and themselves.
https://www.macrumors.com/2012/06/10/a-bit-of-history-behind...
A lot of the guts are shared with iOS, which runs natively on those chips already. I think it's safe to assume they have internal macOS builds running on their A series processors as well. They've probably been testing that for years now.
NeXTSTEP/OPENSTEP ran on x86 already. The early Apple releases, called Rhapsody, were released for x86 and PowerPC.
It's possible they dropped support for x86 in early Mac OS X Server 1 releases (1999/2000), and readded it around the time of Mac OS X 10.0 to 10.2 (2001/2002), but I expect there was support in the codebase for the whole time.
It may have been practically unmaintained (and untested, and maybe even without ensuring it compiles), but I doubt they actually removed the x86 code that was there.
It's not inconceivable that a lot of the previous x86 compatibility was lost or broken at that time. Certainly anecdotes from the Marklar x86 skunkworks team indicated that they spent about 2 years porting and fixing a lot of bugs, which had to be submitted to the normal kernel team via patches that were very carefully written to seem as though they were requesting changes related to niche PPC behaviours (for instance, the PPC was bi-endian, so you could plausibly start submitting changes related to various endian brokenness as if you had tried to use that).
And of course, other layers -- Quartz, Carbon, I/O Kit, and a bunch of others, had never existed in NeXTSTEP and may have needed their own porting work from scratch. NeXTSTEP ran on x86, but a lot had changed since then.
And things that were rewritten from scratch for Aqua (in 10.0, like the entire graphics stack) will have never run on a little-endian system, and those alone would be a major porting effort.
This would allow Apple to avoid much of the overhead of software emulation and I'm sure AMD would be happy to play along since it gets them a (thin) slice of Apple's margins which they would otherwise not have. After a few generations when x86+ARM fat binaries are the norm in the MacOS ecosystem they could drop the x86 decoder (falling back to software emulation only) and presto.
Last time, the Mac platform basically existed in isolation, thus the only problem was that apps for this platform had to be recompiled. This time, the Mac is no longer isolated - millions of developers write client- and server-side applications on Macs that are to be run on mostly x86-based servers, and their toolchain implicitly relies on the architecture being the same on dev and prod machines. That is not to say that it's impossible to change the architecture of the dev machines to something else - it's just a huge additional drawback that was not to be considered at all back then in the PowerPC->x86 transition.
These two facts tend to get downplayed or overlooked pretty frequently when it comes to the "ARM-based MacBooks" discussion, but I consider them fairly substantial and they dampen my enthusiasm for such a transition quite a lot.
I've done a fair amount of development work on both an ARM Chromebook and a Raspberry Pi, and I didn't run into any major issues.
It depends heavily on your tech stack, though. I find that developing on ARM and deploying to x86 was no big deal with Node, Python, and Go. Your mileage may vary with other languages and VMs, though.
They are also in a position to isolate themselves again now.
There are also a lot of people only using their Macbook for presentations, text writing, or even only surfing the web. Apple's own office suit will be ported to ARM when they change their CPU architecture, Microsoft has Office for ARM available (or at least in the pipeline for 2019), and LibreOffice is available for ARM as well.
If Apple really wanted to do this, they would release their small Macbook (non-Pro) with ARM first and then describe a plan to change to ARM for the Macbook Pro line within a few years. No need for a transition period where emulation takes place, everything important is already ARM-ready. The iMac Pro is another thing, that might actually be harder but I imagine manageable if Adobe etc. are willing to invest/to be paid to support ARM.
The developers that Apple cares about.
There are of course the millions of iOS developers.
And besides that, in any conference, from C to Rust to C++ to Java, you'll see tons of Macbook-wielding developers, often the majority.
And when it comes to keynote speakers at conferences (as opposed to audience) the PC laptop is the exception as opposed to the norm...
Which already is ARM and switching Mac OS to ARM could even be an advantage, so I don't see your point?
90% of apple sales are for ARM computers, bet they'd love to only make 1 OS, would save loads of money
Most command line code installed through homebrew is compiled on the user machine anyway, which leaves the closed-source and legacy UI applications not distributed through the app store (but by the time Macs switch to ARM, OSX probably will forbid to run those anyway).
LLVM bitcode is platform specific. It deliberately isn't designed to be portable.
LLVM bitcode remains architecture-specific (if not platform-specific), you can not just recompile x86 bitcode for ARM.
> or upload fat-binaries with ARM and x86 machine code (NextStep aka OSX did this already a quarter century ago)
That doesn't obviate the need for a transition compatibility layer, complex software can take years to port to different architectures.
Even if they went the full-blown emulation route, A12 is almost an order of magnitude faster than the old designs Windows was running on.