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.
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.
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.
For the purposes of automated machine setup and configuration, I’m going to assume you’re familiar with the following Alchemists projects:
It’s not necessary to be well versed with the above projects, though both support and further explain what I’ll talk about next.
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.
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.
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
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
Should you want to permanently switch to Bash — which I highly recommend — you can run the following:
chsh -s /opt/homebrew/bin/bash
Once machine automation was taken care of, installation of software was relatively quick and painless, with some notiable highlights.
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.
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.
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.
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!