I always keep at least one modern Mac on hand for testing purposes. But it’s clear that the M1-based Mac Mini should not be that Mac. So I’m going to return it and pick up a MacBook Air (M1) or MacBook Pro (M1).

I’m not sure which I’ll be getting yet, but I’ve already started the return process on the Mac Mini and will be getting the purchase price back in the form of an Apple gift card. So I can pull the trigger on a portable M1 Mac whenever that happens.

For now, however, I’d like to wind down the discussion about the M1-based Mac Mini.

You may recall in my quick look at hardware and software compatibility that I mentioned that the set of applications that I rely each day on mostly works well on the M1-based Mac Mini, thanks to a mix of those that have been updated for Apple Silicon and Rosetta 2-based translation for those that have not. The one major exception, I noted, was OneDrive: This app installed and “ran,” but anytime I tried to access settings (for example, to enable Files on Demand), it would “beach ball”—how Mac apps hang—and become unresponsive.

Well, that situation did remedy itself, but it took well over 36 hours. I kept checking back, kept observing the spinning (or stuck) rainbow-hued beach ball, and it kept hanging. Until well into day two, when it suddenly just started working. Whatever, it works, and it works normally now. So that’s good news.

I can’t recall if I wrote about this or just discussed this on First Ring Daily at some point last week, but one of the minor frustrations of my Mac Mini set up was self-inflicted: In using any Mac with a Windows keyboard, there are some key mix-ups to overcome. The worst involve the Ctrl, Windows, and Alt keys on my keyboard, which map awkwardly to Ctrl, Command, and Option/Alt on the Mac because some of the keys are in different positions on the keyboard.

So I eventually ditched the Windows keyboard and mouse set that I use with my PC and connected an Apple keyboard and Microsoft mouse, both Bluetooth-based. I’m not a big fan of Apple’s non-ergonomic keyboards, but it was still the right choice (unless I’d be moving exclusively to the Mac for some reason, which I wouldn’t be).

I also wrote about my early experiences using a technical preview of Parallels Desktop that’s designed for M1-based Macs and that it can, for now at least, only run ARM-based virtual machines (VMs). So I tested an Insider Preview version of Windows 10 on ARM (WOA) per Parallels’ instructions. That also worked quite well, given the limitations of WOA. But I have two quick and related follow-ups.

First, I upgraded the VM to the latest Insider Preview build from early December so that I could test x64 app emulation. (And yes, that means that an M1-based Mac is running WOA virtually which is, in turn, emulating yet another app architecture.) This also appeared to work, but Microsoft provides optimization packages for three specific WOA-based PCs, so I couldn’t (or at least didn’t) install those.

Worse, and this is my second observation, I could never get the Microsoft Store app to successfully launch, meaning that I couldn’t install any x64 apps, like Affinity Photo, from the Store. Looking into this, I’ve found—and a few readers have pointed out—that the Store app is an ARM32 executable, and Parallels on M1 can only run 64-bit (ARM64) ARM executables. (And yes, there are PowerShell-based solutions for getting those apps installed. Life’s too short to worry about that kind of thing.)

Yes, I did test x64 app compatibility in WOA under Parallels, if briefly: I installed the 64-bit (x64) version of Chrome for Windows, and it appears to work normally.

And I should note, too, that Store wasn’t the UWP only app that wouldn’t run: Many/most of the apps that come bundled with Windows 10 wouldn’t run either. If Microsoft ever decides it wants to specifically support WOA on M1-based Macs, this will need to change. (Or, perhaps Parallels will figure out how to use “normal” (x64) versions of Windows 10, and then those apps will run virtually.

Whatever happens, using an Insider Preview version of WOA is not sustainable. This isn’t something Parallels (or Microsoft) can officially support, and some change—either the formal availability of WOA for purchase or x64 VM support—is needed.

And, really, my emphasis on Parallels and Windows virtualization is just that, my emphasis. For the vast majority of customers who adopt an M1-based Mac, this isn’t not going to be a concern. Most people will simply set it up, install the native, translated, and web apps that they always use, and just get to work. That this is possible, for most people, so early in the game is what makes Apple’s work on the M1 architecture so impressive. And WOA, by comparison, doubly depressing.

I’m curious to see if M1 inspires Microsoft and/or Qualcomm to look at backward compatibility a bit differently. WOA currently runs x86—and soon x64—apps using an emulation environment that’s based on the “Windows on Windows” compatibility layer that dates back to Windows NT. Perhaps the translation approach used by Apple is superior for this kind of thing and might help Microsoft move its customer base to this new architecture more easily.

We’ll see. In the meantime, Apple has again shown us all how to manage an architecture transition properly, and without any drama. And while an M1-based Mac is still just a Mac, that’s sort of the point, isn’t it? WOA, after all, is less than real Windows. For this kind of thing to work properly, it needs to be boring. It needs to not impact regular users. And that, folks, is an impressive achievement.

Tagged with Apple M1, Mac mini, Parallels Desktop, Windows 10 on ARM