I am celebrating my 30th year working this week in technology product management, marketing, strategy, and research. All 30 of those years involved processors in some way shape or form, so when a big topic like the potential for Apple to create its own processors for its Mac line comes up, I will weigh in on it.
Before you read this article, I urge you to read this article on Apple’s strategy to dominate silicon that I wrote three years ago predicting that Apple would offer iPads with a real keyboard and mouse support, design its own modems and challenge AMD, Intel, NVIDIA on CPU and GPU. Many called me crazy, but it is not looking that crazy now.
Given that backdrop, I would like to list out the top questions I think the press, analysts, developers, and end users should be asking Apple at WWDC.
In one of the industry’s worst kept secrets, Apple is rumored to be developing its own custom line of processors for the Mac line. My assumption going in is that the company will not attempt to immediately to cover its entire MacBook to Mac Pro line with its new processors, but gradually start at the bottom of the performance tier on a MacBook and Mini and move up over a few years.
For the uninitiated, think of an “instruction set” (x86/Arm/MIPS/RISC-V/POWER/etc.) as the native “language” an application speaks to the operating system which speaks to the firmware which speaks to the processor. All four of those (app/OS/firmware/processor) need to be aligned for a system to operate. By swapping out x86 for Arm, Apple and developers would need to rewrite, recompile, or emulate x86 apps to work with an Arm-based Mac, unless written in Swift.
End user benefit
First and foremost, Apple’s shift to its own silicon, which may cost developers a lot of time and money, needs to benefit the end user. Without that, Apple shouldn’t be doing it, even if it’s doing it to save money. And compared to smartphones, tablets, smartwatches, and headphones, Apple hasn’t done well with computers in terms of growth at a small 7-10% market share; it needs to do something. So how did we get here?
In Apple’s grand plan, I think Apple thought the iPad would eliminate the need for notebooks, and we would all have progressively larger and larger iPads. The issue was that the pesky Windows notebook vendors Dell, HP, and Lenovo, and Surface, technologically enabled by tech providers Intel and Microsoft, showed in most attributes, it could offer a better value proposition in most use cases than the iPad Pro.
When the iPad first emerged, Windows laptops were thick and chunky, loud, got 3-4 hours of battery life, didn’t have touch, were slow with hard drives, didn’t have an app store, didn’t have 3G or 4G, and were hard to secure. I carried a 10” iPad for five years along with my notebook for those very reasons, and it would annoy many Windows PC OEM executives I met with. I responded, “build something that eliminated the need and I’ll stop carrying it.” And they did.
As Apple limited innovation in its MacBook line and piled resources into iPhone and iPad, newly architected Windows notebooks flourished and put Apple in a very awkward position. You just have to look at the Microsoft Surface line to see the dramatic change of the Windows notebook or detachable. Compared to the iPad Pro, for most workloads, premium Windows-based notebook and detachables outperform, offer full touch, get better battery life, more innovative form factors and materials, have better keyboards, and are less expensive. I think this is why Apple compares the iPad so much to a Windows notebook and incessantly says “it’s a computer.”
In my opinion, the culmination was that Apple CEO Tim Cook had to go on a tour apologizing for Macs and saying the company will try harder.
With this as a backdrop, what would this shift really do for the consumer?
I expect that Arm-based MacBooks, at first, will mimic what Qualcomm and Microsoft are doing with the ACPC (Always Connected PC). So, I believe Apple will talk:
- Multi-day battery life, month standby
- Fanless operation
- Thinner than today’s MacBook Air
- LTE, maybe 5G connected
- Always-connected like an iPhone and iPad where apps like Mail and Calendar update in the background so data is always “fresh”
- Tighter phone and computer integration
I also think Apple will talk about massive performance per watt gains and overall performance gains and all the iOS apps that will run natively on it. The challenge of this is that it will require a lot of developer work for apps not developed in Swift. I talk in detail below how I think Apple will demonstrate this and the questions I have about that below.
Emulated performance on X86-based macOS apps
I believe it could take up to ten years for “all” macOS software to move from x86 to Arm. There are nuances to “all” apps, of course, like “most,” “popular,” “relevant,” and “Apple” apps, and it is imperative to the conversation that you ask precisely what Apple is referring to with its claims.
Therefore, emulated performance is the most critical question to be asking right now. How will the tens of billions of dollars in apps current Mac customers bought to run on these new platforms?
Emulation has an overhead, and it’s important to know what that overhead is for different workloads and programs users purchased over the past 15 years for macOS:
- Office 365
- Chrome web browsing
- Adobe After Effects, Illustrator, InDesign, Lightroom, Photoshop, Premier Pro
- Home finance like TurboTax
- Virtualization like Parallels to run Windows apps
Be sure not to confuse iOS apps on macOS that are typically less featured and are actually native Arm apps.
I expect that Apple will show some big number claims on synthetic benchmarks like Geekbench that don’t necessarily have anything to do with real application performance. To this day, Apple still hasn’t explained or detailed out the benchmarks supporting iPad Pro “faster than most PC laptops” performance claims, and I do not think it should get a pass here.
Native performance on recompiled or native Arm-based macOS apps
Native Arm performance on new apps or recompiled apps is what Apple will likely talk about most on Monday. The company wants to stay away from emulation as it’s messy. Microsoft has been working on it for a decade since Windows RT, and it’s tough.
I expect that Apple will not want to go toe to toe yet on the CPU with the raw performance on real apps of an Intel Core i9 or even a high-end Core i7 at launch. I think it will likely highlight and leverage apps that are hard-coded to its own GPU and NPU (Neural Engine) designs with its proprietary Metal GPU and Core ML NPU APIs. You see, this is exactly what it does on its current Bionic processors to rack up giant scores and capabilities.
A perfect example is video transcoding. The reason an iPhone can do 4K transcoding well has very little to do with Bionic’s CPU; it is hardcoded to an ASIC on the GPU that only supports a few CODECs. Compare this to what professional video editors do, which is to use a giant, multithreaded Intel Core or AMD Ryzen, which provides the highest quality video output.
Realize that developers would need to rewrite an app entirely to move CPU functions off to the Apple NPU and GPU.
If you believe the full-scale move from x86 to Arm will take five to ten years, a competitive roadmap matters. Otherwise, Apple will be in the same position when it reached the end of its PowerPC roadmap.
I expect that Apple’s first home-grown processor for the Mac will heavily leverage its Bionic processor design for the iPad, and more CPU plus cache, more NPU, and GPU cores, and be used in an entry-level MacBook Pro and an entry-level Mac Mini.
It is vital to ask Apple how and when it will address the iMac Pro and Mac Pro with its own processors. This is because there are going to be challenges for Apple to scale a low-power design to a place where it can be competitive with the highest performance CPUs from Intel and AMD.
Many of Apple’s rock star silicon architects and developers that created Bionic have departed for startup Nuvia, which I covered here, and I wonder how much brainpower went with it. I think we may see Nuvia founder John Bruno, Manu Gulati, and Gerard Williams III fingerprints on Apple’s first out Mac processors, but how about the more critical follow-ons? Time will tell.
Don’t let anyone on Monday convince you that peripherals don’t matter and that they are all wireless. Many peripherals are wireless, but if all were, a MacBook Pro wouldn’t have four USB-C ports.
When you change instruction sets from x86 to Arm, many peripherals will work, but not all peripherals will work without developers cracking open and rewriting the driver.
Today x86/macOS supports all USB peripherals. This is because Apple on x86/macOS supports all-new, through the OS and legacy USB drivers. USB-C on phones and iPads on iOS has limited USB-C support in the OS, and hence do not support all USB peripherals without custom-written drivers. For Apple to support USB-C on Arm/macOS, peripheral makers will have to rewrite USB drivers not supported in the OS. When Qualcomm and Microsoft developed a WOA (Windows On Arm) system, it ported over drivers only built in the OS and did not support legacy devices.
So, I expect Arm-based macOS devices to have limited USB support unless Apple has done a lot of ports to be backward compatible. Peripherals that can only be used with the peripheral maker’s apps add a second level of complexity because the driver and app may need to be worked on. Printers, scanners, cameras, mice typically have apps or applets included.
Therefore, the key questions are:
- What specific peripherals will work on day one?
- Of those peripherals that don’t work on day one, will they ever work?
- If that peripheral doesn’t work, do users have any recourse from Apple or the peripheral manufacturer?
- If there’s a pledge from Apple or a peripheral maker that they will work in the future, when will they work, and will it have all the features supported?
- Do the apps linked to the peripherals also work?
- How expensive are these ports, and what’s the payback for the peripheral maker?
You can find Apple Mac accessories here.
Developer investment to port and support apps
As I’ve already discussed, apps will need to be emulated, recompiled, or rewritten for Arm/MacOS.
There are two types of apps available on macOS. Ones written in Swift (Apple’s development environment) and others written in different flavors of C” (C, C++, C#, Visual C). If apps are written using Swift, the port is straightforward. If you recompile the apps using Apple’s Catalyst, the Apps should run on Arm/macOS. Apps written in any other language will need to be recompiled, and hand-tuned to run on ARM/macOS. I’m not sure precisely what Adobe or Microsoft use, but given they support different operating system platforms, they don’t use Swift and therefore use a flavor of C instead, and this will require recompile and hand optimizing.
So, the questions are:
- How expensive will it be for developers to recompile or rewrite and retest their Arm/macOS applications?
- How expensive will it be for developers to now support two applications versus one?
- What are developers getting out of their investment? Is this a new or larger market for developers?
- What kind of support will Apple provide to these developers to streamline the process?
Important WoA (Windows on Arm) application developers did make the move as they saw an incremental market opportunity with the Always Connected PC.
Intra-line positioning with MacBook and iPad Pro
If you believe Apple will borrow the ACPC positioning from Microsoft and Qualcomm like I did and illustrated above, then it could put Apple in more of an intra-line positioning difficulty with the iPad Pro. Each year, the iPad Pro adds similar capabilities of the MacBook, like “full-size” keyboard, mouse and trackpad support, improved multitasking, USB-C, “Pro” content creation “workflow” capabilities, higher-end accessories, 1TB storage, and even gaming controllers. Retailers tell me the iPad Pro’s #2 most popular accessory after a case is a keyboard, so it’s clear users want keyboards to use as a computer.
Apple is a master at positioning and marketing, and I’m looking forward to how it gives reasons for both to exist. There’s a possibility Apple will not add LTE or 5G to the new Macs, and I don’t expect touch to be added, so it’s possible these will be the differences.
What will Apple do with the $100-150 BOM reduction?
It’s easy for me to estimate that Apple could save on average $100-150 per system using home grown processors. So, the question is, what will Apple do with the money? Will it take it as a price reduction, increase its profits, or add other special features to go margin-neutral? Given the cost reduction, I think Apple should lower its prices, but I don’t think it will.
I expect Apple to announce at its WWDC Monday that it intends a multi-year transition from Intel processors to its own home-grown Arm-based processors for its Mac line of computers. I don’t think there is nothing inherently “good” or “bad” in this move as long as Apple is doing this for the end user instead of approaching this as a supply-chain exercise to reduce costs and increase profits on the backs of developers and end users.
This doesn’t mean it is risk-free. As we have seen with all the work Microsoft has put into two generations, one that went horribly wrong with the original Surface and one that seems to be doing well, these transitions are difficult. I understand why Microsoft created the ACPC platform as it was an incremental market opportunity for its Windows developers and OEMs. It’s unclear to me what that additional opportunity this opens for Apple’s developers that they don’t have already. Apple developers already have access to computers, tablets, smartphones, wearable, so what new market does this open? All I can think of is that it expects to take a larger slice of the PC market with the new platform. If not, then why put developers and users through all the hassle?
I will tune into WWDC like many in the industry will on Monday and will do my best to map what Apple said to these critical questions I outlined above.