The letter A styled as Alchemists logo. lchemists

Putin's War on Ukraine - Watch President Zelenskyy's speech and help Ukraine fight against the senseless cruelty of a dictator!

Avatar of Brooke wrapped in a grey scarf and wearing a black jacket with a red zipper against a slightly blurred background of fall colors of mainly orange leaves. Brooke Kuhlmann
Published March 1, 2021 Updated September 4, 2021
Cover
Apple Silicon

Without a doubt, Apple’s M1 chip is a giant leap forward. To quote directly from Apple:

M1 is here. Our first chip designed specifically for Mac, it delivers incredible performance, custom technologies, and revolutionary power efficiency. And it was designed from the very start to work with the most advanced desktop operating system in the world, macOS Big Sur. With a giant leap in performance per watt, every Mac with M1 is transformed into a completely different class of product. This isn’t an upgrade. It’s a breakthrough.

While I don’t often buy that level of hype, having experienced the power of the M1 chip, I’m way more impressed than I thought I’d be. Over the course of this article, I want to walk you through some of my experiences with the M1 chip, including using the new hardware and how to configure your M1 machine for software engineering purposes.

Specifications

My M1 machine:

  • Model: MacBook Air (M1, 2020)

  • Operating System: macOS 11.2.2

  • Memory: 16 GB

  • Storage: 500 GB SSD

I opted to pick up the MackBook Air instead of the MacBook Pro. While I love the convenience of being able to take the Air with me wherever I go, I generally work in my home office. Also, I don’t end up using the MacBook keyboard much — especially, the Touch Bar which, by the way, is rumored to be removed soon.

Observations

As noted the M1 chip is a significant upgrade that beats the performance of my previous Intel-based MacBook Air and MacBook Pro. Here’s what I love the most:

  • Performance: The Apple M1 chip is crazy fast in multiple areas: boot time, system wake, login, application launching/switching, compiling/building code, etc.

  • Display: The screen is much clearer and more vibrant any of my previous machines.

  • Keyboard: The keys are more comfortable and provide better feedback with the scissor switches versus the previously controversial butterfly switches.

  • Battery: I’m getting over double performance in battery life compared to my previous MacBook Air which is three years old now.

  • Security: With previous machines, being able to lock down your machine via the Startup Utility was a slight hassle, as explained in the macOS Configuration Pre-Install steps. Now all you have to do is turn on File Vault and you are done. 🎉 You can still configure your startup options via the Startup Utility by holding down the power button during startup and then selecting Options from the menu.

Configuration Automation

For the purposes of automated machine setup and configuration, I’m going to assume you’re familiar with the following Alchemists projects:

  • macOS - Base project for machine setup automation.

  • macOS Configuration - Specific machine customization and refinement built on top of the macOS project.

It’s not necessary to be well versed with the above projects, though both support and further explain what I’ll talk about next.

Homebrew

In the past, switching my development environment to new hardware has been fairly trivial. All that was required was to run the Bash scripts found in my macOS Configuration project, mentioned above, and you’re done! In this case, configuring an M1 machine was more complicated because of changes in Homebrew 3.0.0, which switched where Homebrew -- and corresponding formulas -- are installed on Apple Silicon hardware as shown below:

# Silicon Machines
/opt/homebrew
/opt/homebrew/bin

# Intel Machines
/usr/local/Homebrew
/usr/local/bin

Due to these changes, several of the macOS, macOS Configuration, Dotfiles, and Alfred project scripts also needed updating. I decided to handle this by determining the machine’s architecture as follows:

/usr/bin/arch  # => arm64 (Silicon) OR i386 (Intel)

As long as /usr/bin/arch equated to arm64, it only became a matter of teaching the scripts to toggle the Homebrew paths for Silicon and Intel hardware accordingly.

Rosetta

Due to Apple Silicon being so new, you’ll need Rosetta 2 installed in order to allow applications originally built on Intel to run on Silicon. From the command line, you only need to run the following to install:

softwareupdate --install-rosetta --agree-to-license

This remains the same as the macOS project.

Shell

In terms of ensuring the Bash scripts would run on either Silicon or Intel hardware, I opted to construct a long path that would support both (with Silicon taking precedence). Then I only needed to ensure Bash was properly configured by overwriting the following files:

# $HOME/.bashrc
export PATH="/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/opt/homebrew/sbin:/usr/local/sbin:/usr/sbin:/sbin:$PATH
# $HOME/.bash_profile
if [ -f ~/.bashrc ]; then
  source ~/.bashrc;
fi

Unfortunately, Apple no longer supports Bash and has switched to ZSH. Due to this change, you’ll default to using /bin/zsh instead. As long as your shell scripts start with the #! /usr/bin/env bash pragma, you’ll still use /bin/bash. Later, once you’ve installed a modern version of Bash via Homebrew, all scripts will automatically switch to using /opt/homebrew/bin/bash. 🎉

Should you want to permanently switch to Bash — which I highly recommend — you can run the following:

chsh -s /opt/homebrew/bin/bash

Outliers

Once machine automation was taken care of, installation of software was relatively quick and painless, with some notiable highlights.

GnuPG

For some odd reason, after switching over to my new Apple Silicon machine, I found I couldn’t sign my Git Commit messages anymore. This hasn’t been a problem when rebuilding Intel hardware in the past. In response, I found when running a test:

echo "test" | gpg --clearsign

I’d then end up with the following output:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

test
gpg: signing failed: No pinentry
gpg: [stdin]: clear-sign failed: No pinentry

Turns out, I needed to temporarily kill my GPG Agent via the following:

gpgconf --kill gpg-agent

Then I could attempt to sign my commit message which would force GnuPG to prompt me for my GPG passphrase to be stored in my Apple Keychain. I’m not sure if this issue will crop up for others but it tripped me up for a while. Also, make sure to attempt to sign a commit message immediately after killing your GPG Agent because it will respawn itself if you’re not hasty.

Terraform

Initially, Terraform wasn’t built for the M1 platform. Once you could install it, though, the other issue was waiting for various plugins to catch up. Should you be in this situation, you might enjoy my article on building your own local plugins to work around this issue.

Docker

For those of you developing with Docker, you’ll want to install Docker Desktop for Apple Silicon because the standard desktop client won’t work with the M1 chip. You might also be interested in learning how to build for multiple architectures with Docker.

Homebrew Formulas

Sadly, at the time of this writing, the following formulas are not installable on Apple Silicon hardware:

Hopefully, these will be updated soon. Your mileage may vary, though.

Security

These are the known and major security issues:

  • M1RACLES (CVE-2021-30747) - Details a disturbing security flaw in M1 chips which allows two applications to covertly exchange data even when using different user accounts, privileges, etc.

Conclusion

Hopefully, my experience configuring a new M1 machine was of help/interest to others doing the same. Of course, feel free to build your own scripts on top of the macOS project or fork the macOS Configuration to suit your personal needs instead. Either way, I hope you enjoy the performance improvements of your new Apple hardware as much as I do!