You have to take your hat off to Apple: it knows how to transition from one processor architecture to another, completely incompatible one. It did it in the mid-1990s with the switch from the Motorola 680×0 series to PowerPC, then again a decade or so later when it put Intel inside new Macs. Now we get ARM.

Yes, most users will find it a smooth move. Apple’s Rosetta 2 system, which provides compatibility with software compiled for the old x86-64 architecture, runs very well on Apple’s arm64-based M1 chip, so sideloaded or reinstalled GUI apps should work just as well on new Macs as on old ones . All the ones I’ve tried so far do, and there’s no appreciable drop in performance moving from a 2017 MacBook Pro to the latest model. Even the printer works.

But there are some gotchas. Power users in particular should expect occasional moments of frustration. I did, and here they are:

Rosetta

Bizarrely, Rosetta does not come pre-installed. macOS asks you if you’d like to download it when you first double-click on an x64-64 app, and the dialog doesn’t — or didn’t for me — leap to the fore. That left me double-clicking on the newly installed Visual Studio Code icon waiting for something to happen. It never did.

Now I know first runs of x86-64 code can take up to 20 seconds before the app actually launches, so I wasn’t in a frenzy of clicking, but I did curse a few times. Then I coincidentally cleared away arm64 app and Finder windows and saw the ‘do you want to install Rosetta?’ dialog.

That done, it works a treat.

Homebrew

The next frustration is that — quite understandably since it’s an open source project run on a volunteer basis — is that Homebrew, the Mac package manager that I use, isn’t arm64-compatible yet and will therefor not install in the usual way.

For me this was a big issue: a lot of the production code I run — up-to-date versions of Python, Node, Sass, the Hugo static site generator, various Git repo management tools and more — are installed and updated using Homebrew.

The good news is there are a couple of workarounds. One uses the arch command to specify which architecture you want a named command to use. This allows you to select x86-64:

/usr/bin/arch -x86_64 /bin/bash -c "$(curl -fsSL \
https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

The snag of course is that you have to run everything that way, and you know that you’ll keep forgetting to add it to the start of commands. So, for me, the other option is better: run macOS’ Terminal app under Rosetta.

You do this by selecting the Terminal icon, clicking Command–I to get the Info panel and checking the Open in Rosetta box. Now Terminal will run in macOS’ x86-64 compatibility mode, as will all the code running under it.

You can then install your Brew and Brew-sourced software in the usual way.

The quid pro quo is having to use compatibility mode for command line stuff, but I think that’s a small price to pay for convenience in the short term. Homebrew will be updated in due course and it will then build am64 apps from source. You might need to do some clear-out work at that time, but that’s not hard.

My own command line tool, pdfmaker, is not built from source and is already compiled for arm64 usage — it’s just in final testing pending release. I haven’t yet checked whether running a x86-64 Terminal means command line tools must run in compatibility mode too. I’ll check and report back.

Shell

One downside of no Homebrew — well, until I figured out the workaround — was no up-to-date version of bash or the Nano text editor. I’ve quite a few shell scripts that make use of features in bash 5 and above, but macOS comes with a much older release. Fortunately, the Homebrew workaround solves all those issues by allowing me to re-install bash 5. By then I had already downloaded the Nano source code and built it manually (easily; clear instructions in the Read Me file).

Cocoapods

I use Cocoapods for Objective-C library management in one project I work on, and it’s broken on the M1. To be fair to Cocoapods, this appears to be an issue with macOS’ pre-installed version of Ruby, but it means I can’t update pods for the time being. Fortunately, the source code is already there in the appropriate Git repo, so at least I can build code.

Other items

This a grab-bag of upgrade observations, comments and tips:

• Much as like to type on the old-style MacBook keyboard, too many keys failed through crud getting into the mechanism. The move to the older keyboard design feels odd, but its relative resilience is welcome.
• Overall performance feels good — it’s all quick and very responsive. Native apps launch fast. I look forward to running some tougher workloads when I get everything installed.
• I could not get Pixelmator Pro to reinstall. I think this will be fixed when the next major release, version 2.0, with M1-compatibility, is released in the next day or so.
• I built a universal binary of the Electric Imp app development tool Squinter. It runs perfectly on an Intel Mac but fails on the new machine. The reason? The ARM Mac doesn’t like the Sparkle x86-64 code embedded in the bundle. There may be a fix for this, but I can’t use Cocoapods (see above), so I may need to pull the Sparkle upgrade management functionality for time being.
• The new Macs ship with Big Sur 11.0. I didn’t think to check, so it’s probably best if you run System Preferences and grab 11.0.1 before you install anything else.
• My apps MNU, pdfmaker and PreviewMarkdown all run well as arm64 apps — expect updates very shortly.