What does Apple Silicon mean for the Raspberry Pi and ARM64?

Note: There's a video version of this blog post available here: What does Apple Silicon mean for the Raspberry Pi and ARM64?

Apple Silicon and the Raspberry Pi

A couple weeks ago I tried using the latest Raspberry Pi 4 8 gig model as my main computer for a day, and I posted a video about my experience.

Besides many diehard Linux fans complaining in the comments about my apparent idiocy caused by being a Mac user, the experience taught me one thing: A lot of software still isn't built for 64-bit ARM processors, or even for Linux in general.

But there's one trend that I'm seeing: most of the open source software I use already works great on a Pi 4 running on its 64-bit ARM processor.

In my testing, I used the latest 64-bit Pi OS beta, and I think the Pi Foundation had excellent timing releasing it this year, since many more applications can run on a 64-bit architecture nowadays, and because the newest Pi 4 models have much more RAM to take advantage of the architecture.

I could run the LAMP stack, Docker, Kubernetes, GitLab, Drupal, Wordpress, Minecraft, and almost all the Docker images I normally run on my Mac and in production.

For some things, I had to recompile or build my own Docker image, but most things are actually already built for ARM64, and I noticed I didn't have to spend as much time compiling things myself.

Earlier this week, Apple announced 'Apple Silicon', which is marketing speak for 'Apple's ditching Intel x86 CPUs and will use 64-bit ARM processors in Macs'.

And they dedicated a whopping 17 seconds (sarcasm: noted) of the WWDC 2020 keynote highlighting "new virtualization technologies" on the Mac.

Virtualized Docker and Debian VM environments on macOS Big Sur

What does this mean for the Pi and other inexpensive single-board computers? I think this is great news. And listening to Daring Fireball's podcast interview with Craig Federighi, there was even more interesting news:

Craig Federighi on Daring Fireball podcast talks ARM64 virtualization with Apple Silicon

Craig mentioned that the virtualization on the new Macs won't support X86 at all. He even explicitly called out Docker containers being built for ARM, and being able to run them on ARM instances in AWS.

I'm not going to discuss the lack of Windows support or Boot Camp on the new Macs since that's only tangentially related, but I do think there's one very positive implication: as Apple moves off of the X86 platform to 64-bit ARM, more and more organizations and developers will see the importance of building multi-arch Docker images, and also making sure their software compiles on ARM processors like the ones in the Pi.

Like I said earlier, there is already some good momentum in that area. What I think is going to happen is that momentum will start turning into a full-on freight train, and we're going to see the default for most software being "it runs on ARM and X86" instead of the current status quo, which is "it runs on X86, and might run on ARM but it's not really supported that way."

Even if many developers like me decide to jump ship off Apple's platform after macOS 11 is released, there's enough momentum in the Apple ecosystem, and in the computing world in general, to really push the ARM transition forward.

I feel like Apple's announcement at WWDC echoes earlier major changes, like dropping floppy drive support in the first iMac, adopting USB when most of the industry still used serial ports, or abandoning Adobe Flash before it was the 'cool' thing to do.

Microsoft has been trying to diversify into the ARM ecosystem for a while now (e.g. the Surface Pro X), but their Windows app support for ARM has been lackluster since they have never really forced developers to support it or even come up with a solid transition plan.

Maybe with Apple's announcement this week, the small amount of momentum ARM has had during the 2010s will turn into a landslide, and we'll see the architecture duke it out with X86 for the next decade, especially because of how important mobile, power-efficient, and edge computing are today!

If you liked this post, you might also be interested in my Raspberry Pi Cluster series featuring the Turing Pi.

Comments

I'm wondering whether this will make Microsoft consider doing a full-fledged ARM port of Windows.

The Surface Pro X (with a 3 GHz ARM CPU, the 'Microsoft SQ1', jointly developed with Qualcomm) is their current main salvo, but Microsoft has been working on ARM Windows since I believe at least 2012. They have a lot to show for it (e.g. Office already runs on ARM), but the vast Windows ecosystem would also need to change direction to at least have some sort of 'fat' binaries (like with Apple's 'Universal' apps), and I don't see that happening soon, unless Microsoft finds some way to really incentivize developers.

ARM Surface tablets come with x86-32 emulation (with 64bit support down the track).

But right now there's no incentive for Windows developers to release aarch64 ports of their Windows programs if there's no readily available cheap box for them to test on. If Microsoft were serious about developer mindset on Raspberry Pi, they'd complete the unofficial port by volunteers to the 8GB rPI4 and license it officially for FREE that platform - whereby anyone with Visual Studio has a $75 box to test on. Test on a Pi, run on a Surface X or aarch64 Windows 10 Azure instance...

I look forward to seeing your video review of Windows 10 running on a 4GB Raspberry Pi 4 compute module within your Turing Pi cluster! :)

What does this have to do with Apple? The ball's in Microsoft's court re: ARM64 on Mac in Bootcamp/Parallels as far as business motivations. From Apple's POV, perhaps they'd license their A13 chips exclusively to Surface devices just to cut Qualcomm out of the loop!

I just realized that an ARM64 MacOS would very likely lead to ARM64 Pro Tools support. That would certainly create some interesting possibilities.

Though all the UI bindings would be macOS-specific. I'm guessing companies that make GUI apps for macOS won't be able to easily port the UI and bindings to any form of Linux, barring a Swift-and-AppKit makeover in some Linux distro!