What Apple Silicon means for enterprises, and why it matters
It’s finally official.
In case you missed it, Apple officially announced it would be moving desktops and laptops away from Intel’s x86 processors to its own custom processor architecture—one Apple has been building in the iPhone and iPad for over a decade—officially dubbed Apple Silicon.
While Apple made other significant announcements at WWDC 2020, including previewing iOS and iPadOS 14 and debuting its macOS Big Sur update, the architecture switch of the Mac was easily the biggest unveiling.
How is this going to affect your business, and what steps can you take to prepare? For you, and for Apple, it starts with examining your past.
Not Apple’s first rodeo
Most manufacturers rarely switch processor architectures. But Apple has done it three times before (four if you count the pre-Mac MOS 6502 processors on the Apple II). Every time, the transition was mostly seamless for customers.
When Apple first moved the Mac from the Motorola 68000-series architecture to the PowerPC platform in 1994, it was both a natural progression and a huge step forward. The PowerPC architecture was developed in collaboration with IBM, Motorola, and Apple themselves, and ushered in a new technology: Reduced Instruction Set Computing (RISC). RISC is a way of increasing the efficiency of a processor, performing faster and cooler than one without it (e.g. Intel’s offerings). Despite not leading in raw speed on the spec sheets, PowerPC processors outperformed competitors for years on many tasks, primarily because of RISC.
Apple went to great lengths to ensure older apps would have no issues running on the newer chips. Using hyper-efficient code, there was almost no difference in performance or compatibility. In fact, some apps ran a bit faster. Development environments were also ready ahead of time, with many major applications ready with native code for the launch.
How did Apple get all this right the first time? Simple: They didn’t. Internally, Apple held a design-focused exercise in the late ‘80s around their own self-designed RISC processor. It was code-named “Jaguar,” and it went about as wrong as possible—with Apple having to scrap a whole lot of effort. In short, Apple learned a ton from their mistakes, and the subsequent PowerPC partnership and launch was executed as perfectly as possible.
More than a decade later, in 2006, the playing field had changed drastically: The newest PowerPC G5 processor just couldn’t be fit into a laptop. Meanwhile, Intel’s “less-optimized” processors had more than enough raw power to make up for it. Plus, miniaturization and advances in power management meant no compromise when it came to battery life and energy use. Intel was ready for Apple.
And Apple was ready for Intel. Apple had been actively testing its operating system on Intel hardware years before it made the actual switch. When it made the official move, it was another smooth transition.
Fast forward to today. Given Apple’s history of successful platform switches, the two-year transition timeline for Apple Silicon, and the tools available to developers and users to support the switch, enterprises have little to worry about.
But there are a few steps you should take to ensure the best transition.
Worried about compatibility issues? Not so fast
Apple’s approach to architecture changeovers is to cover the past, present, and future with tools to seamlessly transition from one processor to the next. With some minor exceptions, each time Apple switched processors, apps were compatible from one device to the next. Apple has been planning for this trend to continue as it switches to its own silicon chips.
Luckily, one of the toughest theoretical barriers to Apple Silicon—its exclusively 64-bit architecture—is also one that Apple has accounted for. The company deprecated 32-bit apps on its platforms over the past few years, with macOS Catalina removing the ability to run them entirely. Developers have known they should be writing 64-bit apps for Mac for the better part of a decade, so they shouldn’t encounter any issues now.
Giving developers the right tools to prepare can always be a challenge. For present and future development, macOS Big Sur introduces Universal 2, a sequel to the Universal Binary formats that Apple has used in the past. Universal 2 lets you write apps that will run natively on both the Intel and Apple Silicon platforms. This means that developers can distribute a single package, from a single codebase, regardless of what the end user is running.
Another bonus for developers is Mac Catalyst, a new option that lets developers offer their existing iPadOS apps on macOS, using most of their existing code, and implement new macOS features nearly instantly.
Rosetta 2 is another sequel that automatically translates code from Intel’s x86 to Apple Silicon in real-time. The original Rosetta aided the transition from PowerPC to Intel, translating it in real-time with extensive compatibility and very little impact to the end user. Rosetta 2 will do the same for Apple Silicon.
Rosetta 2’s performance, of course, is a big question. Apple has already announced that while it can translate most Intel-based apps, it won’t work with virtual machine apps that virtualize x86_64 computer platforms. However, considering Apple’s history of successful machine code translation, I have a lot of confidence in its overall performance and compatibility for most apps.
Even a well-worn path may contain pitfalls
Of course, there are definite risks. Most notably, how will developers react to this new architecture?
The neat thing is, they already have: Developers have been writing apps in Xcode for iOS, iPadOS, and macOS for years, and most have been targeting at least one form of Apple Silicon since its introduction. In fact, Apple has included the chip from their iPad Pro, the A12Z Bionic, in the development kit for Apple Silicon. Every iOS and iPadOS developer now has a head start on development for macOS.
Another concern: How compatible will Apple Silicon be with older code?
Most organizations don’t have anyone who can rewrite or recompile all their code for a new platform. And many times, businesses have written complex applications that are dependent on the older architecture. For now, we’ll have to wait and see. But given the two-year transition period, current availability of beta software, and code parity with iOS and iPadOS, enterprises should have answers long before any compatibility concerns become real problems.
So, what now?
For some organizations, even a two-year deadline may sound a bit daunting. But there are steps you can take today to make that date uneventful.
First, ensure your developers are exploring beta versions of macOS Big Sur, iOS, iPadOS, and Xcode. Registered developers have instant access to this, and beta versions of operating systems are also made available to the public after a short time, free of charge.
Notice I didn’t specify only your Mac developers. That’s because your development organization is much more valuable as a team. Make sure your Mac developers get together with your iOS developers and share lessons learned. They now have a common platform to work with. Any resources they can offer each other will pay dividends once the hardware becomes available.
If you have any questions about Apple’s architecture change or how it will impact your business, contact your SHI account executive.