If there’s any lesson that Apple should learn about supporting apps that run on both X86 and ARM, it’s this one: Tell users which apps support which processor, and actively guide them toward the best experience.
It sounds obvious. But as Apple navigates its transition from Intel X86 Macs to Macs designed around its own ARM silicon, I can’t help but think of the things I wish Microsoft and Qualcomm had worked on to help facilitate the Windows on ARM experience.
It starts with communication. When Asus launched its NovaGo laptop with a Qualcomm processor inside, we explained the pros and cons of the architecture, especially what it could or couldn’t do. Two years later, that article still feels necessary. Here’s how Microsoft stumbled along the way, and where Apple could go wrong too, unless it learns from those mistakes.
Talking to developers but not consumers
No consumer wants to wade through developer documentation to understand why they should or shouldn’t buy a product. But that’s exactly what Microsoft asks consumers to do. How Windows emulates instructions coded for X86 processors into code ARM chips can understand are summarized in a dry support document on Microsoft’s site. That’s not good enough. Microsoft has never made any real effort to inform consumers of what the ARM platform entails, what its limitations are, and what options there are to overcome those limitations.
They’re big limitations, too. Let’s say you want to download the Zoom videoconferencing app on Microsoft’s Surface Pro X. You won’t find it on the Microsoft Store, forcing you to go to Zoom’s site.
What Zoom doesn’t tell you, of course, is that a Windows on ARM PC still can’t run a 64-bit app in emulated mode. So if a consumer tries to download the 64-bit version of the Zoom app on the Surface Pro X, they’ll be faced with a big, fat error message preventing its installation. That’s a roadblock between a consumer and an enjoyable experience, and my bet is it’s one of the biggest reasons why Windows-on-ARM PCs haven’t sold well.
Apple seems to be headed down the same path. Like Windows on ARM, Apple also uses code to translate instructions written for X86 processors into instructions its ARM chips can understand. On the Mac, this code is known as Rosetta, the same translation software that Apple used to facilitate the transition from the PowerPC to X86. Now, Rosetta2 (or just Rosetta) is designed to take code written for X86 and enable it to “just work” for the Mac’s new ARM silicon.
Part of “just working” appears to involve “just waiting.” As Apple says in developer documentation now posted to its site, “the translation process takes time, so users might perceive that translated apps launch or run more slowly at times.”
Users will also have to help their Mac use the right code. “If a binary includes both
x86_64 instructions, the user can tell the system to launch the app using Rosetta translation from the app’s Get Info window in the Finder,” Apple says. “For example, a user might enable Rosetta translation to allow the app to run older plug-ins that don’t yet support the
Rosetta won’t translate kernel extensions and virtual machine apps that virtualize X86_64 platforms, however. Rosetta also won’t translate AVX instructions, which Intel first implemented in its 2nd-gen Intel Core “Sandy Bridge” chips. In 2011.
To recap, Apple is telling developers (not users!) that emulated apps will run more slowly than native code, that users may have to configure an app manually to run in emulated mode to enable full compatibility, and that its translation software won’t process instructions that have been in place for about nine years. This will not be “it just works”—and consumers don’t know that yet.
Making it hard to find compatible apps
App stores are where consumers first interact with apps, and Microsoft’s Store is still bad.
By now, every Windows user is familiar with the store’s many shortcomings. There’s no information telling you when the app was last updated, let alone a changelog. You can’t see the number of downloads to date.
Microsoft buries which processor architecture an app supports, too. If you’re already on a Windows on ARM (WoA) Connected PC, Microsoft will hide incompatible apps. But if you want to know what’s available for WoA Connected PCs before buying one, you’ll have to go app by app to find out for yourself.
In a few years, the question of whether a Mac app is coded for ARM or X86 will become moot, because Apple’s converting the Mac wholesale to ARM. But for now, customers on both WIndows and Mac platforms can choose between the two processor architectures, putting them in the same camp.
Granted, it’s probably too early to expect Apple’s own Apple Store to provide this information. We know that some of its key third-party partners —Adobe and Microsoft, namely—support Apple’s ARM efforts. We can wonder how many of the small niche of Apple game developers will bother re-coding for ARM, and how quickly other content-creation app devs will sign up.
Knowing which apps are coded for each processor, though, is critical. “Universal” Apple apps will run on both platforms. But we really don’t know how Apple’s ARM processors will perform, and we also don’t know how well a given app will run on each platform. It’s important, then, that both Apple and PC customers know which apps are coded natively for a particular processor, where performance will be optimized, and which will be emulated and take a performance hit. The app store —whether on the Mac or on Windows—should be the starting point for this conversations.
Failing to provide ‘showcase’ apps
So far, we’ve been concerned with performance, compatibility, and communication. Another thing Qualcomm and Microsoft have yet to deliver is a showcase PC—not just from a hardware standpoint, but from a software standpoint as well. The answer—and it pains me to say it—is bloatware.
I generally mark down review laptops if they come clogged with unnecessary third-party apps. Acer, for example, includes apps that suggest other apps, like Collection S. But that’s what Windows on ARM (and Macs) need: a showcase of apps, coded natively for ARM, that show off the platform.
On Windows, neither Microsoft nor Qualcomm has stepped up in this regard. Rather than user-generated collections, we should have an official, branded website listing (and linking!) apps that have been optimized for ARM. Connected PCs should be preloaded with ARM-optimized apps, or at least offer a gateway toward an optimized experience. The ability to download optimized Windows on ARM apps could be a feature of Microsoft’s new WinGet package manager utility.
I suspect Apple already understands this, and a portion of Apple’s App Store entitled something like “Runs best on Apple” wouldn’t surprise me. Presenting consumers a collection of the apps they’ll frequently use, reassuring them that they’re optimized for performance, and then adding and updating apps regularly assures customers that the company is looking out for them.
Right now, customers still don’t understand why they should move away from X86 and embrace something new and unfamiliar like ARM. And if they do, the explanation is always framed in terms of hardware. How and why customers should transition their software is generally left out of the conversation, and everyone just ends up confused. Let’s hope Apple will look at the mess Microsoft made and do better.