Bloomberg: ARM Macs in 2021
Mark Gurman at al. (tweet, Hacker News, Slashdot, AppleInsider, MacRumors):
The Cupertino, California-based technology giant is working on three of its own Mac processors, known as systems-on-a-chip, based on the A14 processor in the next iPhone. The first of these will be much faster than the processors in the iPhone and iPad, the people said.
Apple is preparing to release at least one Mac with its own chip next year, according to the people. But the initiative to develop multiple chips, codenamed Kalamata, suggests the company will transition more of its Mac lineup away from current supplier Intel Corp.
[…]
The first Mac processors will have eight high-performance cores, codenamed Firestorm, and at least four energy-efficient cores, known internally as Icestorm. Apple is exploring Mac processors with more than 12 cores for further in the future, the people said.
This is another good reason to postpone or scale back macOS 10.16. We want the software to be in as good a shape as possible before a big hardware transition. Apple will have even less time to fix bugs, and developers less time to work around them.
I expect the ARM transition to be accompanied by removal of lots of APIs, so developers will have to contend with that, as well as porting and testing their own code, and dealing with any dependencies that have broken.
I don’t think unifying the chip architecture would make the app ecosystem any more unified. Apple could do this today if they really wanted to, fat binaries (where different cpu architectures are combined in the same application) have been around forever. Major frameworks are already on both architectures, which is the biggest hurtle. I think the problem is more philosophical, or maybe Apple just lacks the will or vision to actually get it done today, if ever.
Previously:
- The Case for Postponing macOS 10.16
- 2020 Mac Hardware Rumors
- Marzipan As a Path to ARM-Based Macs
- Speculation and Dread for the Next Transition
- Apple Plans to Use Its Own Chips in Macs From 2020, Replacing Intel
- ARM Mac Notebook Rumors
- The Success of ARM
- Apple’s Processor Advantage
- The End of x86? An Update
Update (2020-04-24): John Gruber:
The $64,000 question is whether they’re going to have an emulator for running x86 code on ARM Macs.
Update (2020-05-06): Raphael Sebbe:
About ARM Macs: that would also enable machine learning on laptops. Like in big ways.
ANE is the new dedicated DSP, and with hardware and software stacks already in place, this gives Apple a significant advantage.
Update (2020-05-18): Jason Snell:
The Motorola 68000 era lasted for the Mac’s first 12 years (non-PowerPC PowerBooks… lingered). In 1994, the PowerPC transition began, and Apple shipped Macs with PowerPC processors for 12 years.
At 14 years and counting, the Intel era is the longest in the Mac’s history. The transition was also the fastest—Apple really cleared out the PowerPC Macs in a hurry and replaced them with Intel models.
I still find it hard to believe that the Intel era is the longest and that the OS X era is longer than the classic Mac OS era.
10 Comments RSS · Twitter
@Jean-Daniel Hopefully, WebView and AEWP make the transition, or a lot of stuff is going to break. What else has been on the chopping block for a while?
What else has been on the chopping block for a while?
OpenGL. Open-anything, really; I expect this transition to lock things down, hard.
> But the switch to ARM may be their only chance before very long time to incorporate ABI breaking changes in Swift.
Is that really an option, since it's already locked down for its use on iOS?
>What else has been on the chopping block for a while?
everything marked deprecated
everything under Application Services Framework
everything under Carbon Framework
everything under Quartz Framework
most of Core Services Framework
even more of the UNIX underpinnings
If Parallels can run Windows 10 and Ubuntu on an ARM Mac at least as fast (and with no loss of compatibility) as the current Intel Macs, I'm sold.
@Ben G: There's already an edition of Windows 10 that runs on ARM (and runs intel compiled software using something like Rosetta). Put that in your VM and there should be no slowdown whatsoever except when running X86 software.
@Glaurung, The Windows 10 ARM systems can emulate 32 bit x86 code. However it can’t run 64 bit x86 stuff, which is something Apple will need to have in order to make this transition successful.
Put that in your VM and there should be no slowdown whatsoever except when running X86 software.
To be clear: on Windows, “x86 software” describes the vast, vast majority of software, including much of Microsoft’s own stuff ranging from Word to Visual Studio. Even though Windows on ARM has existed for years, there hasn’t been that much uptake. Part of it is inertia, but I think a big part of it is simply tooling: you cannot, even today, compile a .NET Framework app for ARM. You can do so with .NET Core (with many asterisks), but building GUI apps in Core only became a thing last fall.
So if Apple does offer a “run Windows on ARM on your Mac” option (which I don’t know that they will; for now, I’m guessing Mac on ARM is primarily about the low-end devices in terms of performance; on those, running Windows matters a lot less), they might ironically be one of the driving factors to get a Windows on ARM app ecosystem going.
Oh and, also, “put that in your VM” is in itself a caveat. VMware ESXi on ARM seems to be happening, and they’ll presumably be able to scale that down to VMware Fusion on ARM. For Parallels and VirtualBox, I don’t believe there have been any announcements to that effect.
It would be neat if Apple brought back the G prefix for their ARM Mac chips. Start with the G6 and go from there.
> I expect the ARM transition to be accompanied by removal of lots of APIs
Apple already removed a lot of API during the 64 bit transition. I'm not sure it remains a lot to remove.
But the switch to ARM may be their only chance before very long time to incorporate ABI breaking changes in Swift.
I hope when such switch arise, they will not miss this opportunity.