Apple Silicon – How is Apple Doing This

How is Apple able to pull off a move to ARM when everyone else is struggling?

What is the significance of Apple moving to their own ARM based System on Chip for the Mac, and how are they able to make a switch to ARM when Microsoft has been struggling with it?

This post will walk through Apple’s experience in hardware, software, development tools and technologies, and history of switching platforms to reveal the yellow brick road that got us here.

Hardware – The A series

The big announcement: Apple is creating their own SoCs or System on Chip for the Mac based on an ARM instruction set (the same type of architecture found in iPhones and iPads) as opposed to the x86 instruction set found on Intel chips that are currently inside of MacBooks and iMacs. These new SoCs will include a broad range of technologies that encompass the CPU, GPU, Secure Enclave, and even the Neural Engine.

Let’s break down what this means.

System on Chips represent a growing trend in computing. Previously you’d have many computer chips and components all separate and combine them via circuit boards. Often times these circuit board would include a Central Processing Unit( CPU), Graphics Processing Unit (GPU), and RAM and then be called a “Mother Board”. With System on Chips all of these previously separated chips are combined into one. In many ways mobile computing demands for both more processing capability and a broader scope of device capacities (think WIFI, Bluetooth, cellular) lead the transition to SoCs.

I’m going to focus heavily on the CPU aspect of the Apple Silicon SoC, mainly because it represents the bulk of the shift. As a primer in CPUs, the CPU is the main brain of your computer, and typically, are procured from outside vendors who specialize in creating these immensely important chips. CPUs handle the majority of what makes a computer work and its performance and power consumption dictate many of the characteristics of your computer.

CPUs are created to run specific Instruction sets. Think of these instruction sets as the language the CPU speaks. Traditionally Laptop and Desktop computers run a version of the x86 instruction set, whereas Mobile devices run a version of the ARM instruction set.

Code written for ARM doesn’t work on devices running x86 and vices versus. Think of it like trying to have someone speak Russian to an Italian waiter, they wouldn’t understand each other.

Most Intel processors found in Laptops and Desktops run the x86 instruction set. For years (if not decades) Intel set the pace of the CPU industry, doubling the “number of transistors” every two years (this is a concept known as Moore’s Law, and Moore is conveniently the guy at intel who was in charge of just such a doubling). This double translates into huge performance gains every two years. This was no small task to keep up with

While Intel has been a dominant force in the Laptop and Desktop (and server) processor market, they have struggled to create momentum as smart phones and tablets have evolved. In its place Qualcomm and Samsung have seen quite a bit of success using the ARM instruction set and architecture. Even the initial iPhones were running ARM based CPUs from Samsung.

As Apple continued to evolve mobile computing they recognized the need for a CPU with greater capabilities than any on the market. This led Apple to create the A4 chip, a SoC with an ARM processor which was debuted it inside of the first iPad, and not soon after the iPhone 4. (Interesting history lesson – Apple worked with ARM to create a processor for the Apple Newton, even owning a portion of the company that created ARM at one point.) From a hardware stand point thus begins the steady march to “Apple Silicon” in the Mac.

More than 10 years later the A series chips inside of the iPad Pros are outperforming Intel chips in Windows Laptops in certain benchmarks. This alone should have, and for many did, raise eyebrows.

Software

While the hardware change is the big announcement, due to the switch in instruction set, software actually becomes the biggest complication.

Apple’s focus on creating their own operating systems, and limiting to a set of specific hardware, as allowed them to optimize their software for said hardware. Part of the intention of Metal and Metal 2 (Graphics software) was to allow developers to get as close as possible to the Graphics Processor.

I’ve already mentioned that up until now, Intel based Macs have been running x86 instruction sets, while iPhone and iPads were running ARM. However it’s worth revisiting the fact that iOS was originally (and probably to an extent continues to be) derived from MacOS (back than called OSX). So technically we already have 10 plus years of Mac based code running on ARM devices.

In general, switching to a new architecture and instruction set means every application needs to be recompiled (a process where developer tools take the code we write and turn in into code the computer can run). However, it is possible to translate code from one instruction set to another. This is where Rosetta comes into play.

Rosetta 2 is getting a lot of attention, and it should, it’s a key pillar of Day 1 for Apple Silicon. When Apple previously switched CPUs from the IBM PowerPC to Intel they created Rosetta, a technology that translated apps from one instruction set into another. Rosetta 2 is the update to this tool which will translate Intel x86 to Apple Silicon ARM instruction sets. This basically means that all of the apps you have already installed on your Mac should run day one without any developer intervention.

It’s worth noting, we won’t know how well apps perform using Rosetta 2 versus being re-compiled until more people have their hands-on Apple Silicon Macs. Speculatively, the ultimate goal is to have all of the MacOS Applications out there recompiled for Apple Silicon. This will provide the best performance and compatibility. Once again there is some precedence for Apple to facilitate recompiling and distributing software on multiple CPU architectures.

Software Development Tools and Technologies.

At a high level, after a developer writes code we “Compile” it. A “Compiler” is software that takes a developer’s code and turns it into a version of code that the computer needs to run it. There’s a whole area of Computer Science dedicated to this, and it gets super in the weeds technical very quickly. Needless to say, compiling is broken down into a number of phases which are organized into two groups: “Front End” and “Back End”

This separation allows things to get very interesting, and an area that Apple has actually innovated heavily in.

Now MacOS isn’t the only Operating System created by Apple to make a switch on what chips it ran on. A number years ago Apple’s switch from a 32 bit ARM to ARM64 on iOS devices represented a change in instruction code. This wasn’t as drastic as a switch from x86 to ARM, but it certainly meant that developers had two different types of processors to consider when they made apps.

I give Apple a ton of credit, and even credit over other development platforms, in their constant focus on making development easier. Apple has time and time again gone one step further in any efforts to make development on their platforms as easy as possible. My favorite example of this is when they released Automatic Resource Counting (ARC) for Objective C. There were other ways of garbage collecting already in existence, but ARC was both easy to use, and more efficient.

The most recent example of a processor switch actually exists with Apple Watch, and I think it represents a preview of what we’ll see with MacOS.

In this particular case of switching between version of ARM on Apple Watch XCode, Bitcode, and App Store Servers handled all the heavy lifting

Bitcode and App Thinning

Bitcode and App Thinning are two technologies used by Apple that have laid the groundwork for the distribution of Apps that are flexible enough to work on different platforms, but also efficient in size, containing only code and assets that a users end device needs.

We can think of Bitcode as code that hasn’t been fully compiled yet. It’s gone throughs the initial front end phases of being compiled, but allows Apple to perform the back end Phases for developers. The backend compilation is all done on apple servers pretty much on the App Store side of things.

This allows Apple to take code you’ve written and finalized the compilation of it to run on different processor without Developers needing to worry about this. Again, this happened seamlessly when Apple Watch made the jump to ARM64 in the S4 chip (I didn’t even realize/remember this happened until I was doing research for this post). Developers only had to check a box in XCode, and everything else was automatically handled.

As mentioned by infoq.com –

“Finally, the bitcode on the server can be translated to support new architectures and instruction sets as they evolve. Provided that they maintain the calling convention and size of the alignment and words, a bitcode application might be translated into different architecture types and optimised specifically for a new processor. If standard libraries for math and vector routines are used, these can be optimised into processor specific vector instructions to gain the best performance for a given application. The optimisers might even generate multiple different encodings and judge based on size or execution speed.” https://www.infoq.com/articles/ios-9-bitcode/ That was written at the time of iOS 9, about 5 years ago. We’ll that future is here.

Cleary developers will be able to develop MacOS applications in, check a box in Xcode, and have the App Store Distribute an app of the correct infrastructure to the end user.

History of Switching

Apple has never been shy about changing the architecture used in their computing products. There’s a lot that has to happen to successfully make such a huge shift, and having gone one before provides key learnings and education that informs a new switch.

The current situation with Intel’s Core Chips and Apple is fairly similar to the previous one between IBM PowerPC and Apple. IBMs inability to deliver competitive chips for Apple’s PowerBook Laptops lead Apple to switch to Intel’s Core chips in the first place. Even the PowerPC architecture was a changed from the original Motorola 68K series in the first Apple Macintosh computers.

The Apple Difference

So why is Apple able to move a desktop OS to ARM when everyone else is struggling? The reality is, it’s not like Microsoft can’t do all of this. They, just don’t seem to be. Microsoft worked with Qualcomm to create a custom ARM CPU for the Surface Pro X, but based on initial benchmarks it’s not as fast as the A12Z chip in the Developer Transition Kit.

On the software front Microsoft has the Universal Windows Platform Apps, and their version of universal Apps, meant to run on different Windows Devices. This includes the ability or developers to submit an ARM package of their app, but initial reviews still point to limited app support on Arm.

In summary, Apple’s focus on creating SoC’s that are computationally powerful, include a wide range of capabilities, and have lower energy requirements in the mobile space has lead them to be able to create Apple Silicon SoC’s meant for Laptops and Desktop. Apple’s capabilities in optimized software dovetails into enabling a new hardware instruction set.

Apple’s focus on software development tools and technologies in to multiple instruction sets, and a history of successfully changing architectures uniquely positions them to be successful with the move to Apple Silicon, while supporting Intel chips for the time being.

I can honestly say my next Macbook Pro will be one with Apple Silicon.