My first week with a Macbook Pro using Apple's M1 Chip

Overall, I’ve been really impressed with my new Macbook Pro. I was quite nervous to upgrade because I’ve heard a number of horror stories over the last year (or so) of colleagues who had done the M1 upgrade and found that critical tools (especially those surrounding virtualization, and especially Docker environments) simply didn’t work. While I have experienced some issues in those regards, nearly everything I would categorize as a minor inconvenience and I’ve largely been able to work around the issues. There’s only one critical thing that remains a blocker, and it’s a pretty significant blocker upstream.

This post will dig into the issues I’ve seen, some of the work arounds, and some suggestions for you to look at before you adopt the new chipset!

Exterior and Ports

I’m a fan of small computers, it really helps when traveling. My last Macbook Pro was a 15 inch, and this one is a 14. So that’s super exciting (now I just need to start traveling again). They did stick with the USB C ports (fine, I’ve already got all those accessories) but they did re-add a dedicated HDMI port, which will be uesful and a mag-safe power port. I was a little bummed about this until I discovered that the USB C ports still work for charging. So, I’ll probably tuck the mag-safe into my bag for travel and stick with the USB C I have cable managed on my desk.

Otherwise, no significant complaints or notes! This is a beautiful computer and I’m super excited to play with it!

Initial Setup and Installation

The experience of setting up a new Macbook Pro hasn’t really changed at all since I wrote about it a couple of years ago. Sure, some versions of things have changed, but by and large the installation of “all the things” went very very smoothly. Homebrew continues to be a critical tool for the setup and installation of packages and I can’t imagine living without it! I’m also super thankful for things like Lastpass, PHPStorm’s Config Sync, Google Drive, and Github / Gitlab where all of my project code resides.

The TLDR is that I spent more time downloading software / packages for my computer than I did really “setting” anything up. The only real work was generating new SSH keys and re-cloning repositories. I have operated for years now under the operation / assumption that my laptop is 100% expendable and that lifestyle continues to benefit me in the rare instance where I do get a new computer. It makes setup SO MUCH simpler.

Verdict: no issues with baseline setup and preparation

Project Virtualization

I started running into oddball issues almost immediately when I started spinning up containers for projects. As it happens right now, I’m running projects with both Lando and DDev containers. Normally, these two systems play nicely together (as long as I’m not actively running a Lando and DDev container at the same time). But, I noted that as I was switching between Lando and DDev on the new computer, I was getting some pretty notable local DNS issues related to ports already being used. Specifically:

port 443 is already in use

Previously when I had run into a similar problem it was related to a Docksal issue, so while I didn’t know precisely what was going on here (because I didn’t spun up anything Docksal related) but I had a good idea. It seems like on the new computer, I actually need to not just “stop” my Lando and DDev containers but actually the services as well. This can be accomplished with the commands:

$ ddev poweroff

$ lando poweroff

So, now when I’m swapping between Lando/DDev projects I not only stop the container, I also stop the service and all seems fine.

Verdict: turn off the lights when you leave the container.

Browser-Based Testing

The most significant problem that I’m running in to is related to all the automated testing that uses Google Chrome / Chromium. This is proving to be a pretty major blocker to existing codebases “seamlessly” working on the M1 architecture because most of the Chrome binaries / examples out there for Docker and Lando are actually not compatible with the M1 chip. This issue is further sub-divided into two key issues: Behat / backend testing and NPM / frontend testing.

Behat Testing

Previously, I had been installing Google Chrome directly into the appserver container in my Lando file. I realize is a little off for the typical Docker approach of put everything in its own container. But, BLT has a bunch of baked in capabilities in terms of launching and running behat. This doesn’t work so hot when Google Chrome itself isn’t installed in the container that the app is running in (hence the reason I did this originally).

Thanks to a suggestion from Matt Glaman I am slightly changing / tweaking this approach to add a separate container for Chrome and thanks to an approach first trail blazed by Lindsey Catlett in her DDev BLT plugin I’m not overriding BLT’s default testing functionality to launch a Docker based solution. It seems to work both locally and in CI (which is good, because the CI process shouldn’t have changed). This approach should also still work with non-M1 processors (it’s just different than it was before). See my PR on the Lando plugin.

NPM / Pa11y / Backstop / Puppeteer

This one has consumed most of my day today and I’ve made almost no progress on it aside from determining that:

Pa11y and Backstop both assume Puppeteer is managing Chrome
Puppeteer doesn’t support M1 (yet).
All of the work arounds for this that “work” seem to be intended to run on a host machine and not inside of a Docker container.

As it stands, I’m likely going to have to remove Pa11y and Backstop from the project until Puppeteer resolves their open PR to correct this issue.

Verdict: Behat seems to work fine with the proposed new methodology, Pa11y and Backstop do not (currently).

In Conclusion

As with any / all processor architecture changes, it’s never a great idea to be an early adopter if you want to take advantage of open source software. Supporting the newest and brightest things out there takes time, and costs money (because you can’t test and work on an M1 processor unless you have a new laptop that has a new M1 processor).

I consider myself lucky that most of the tools I use have responded (or are responding) to the architectural changes in the Mac ecosystem. I really appreciate the hard work!

And I have to say, even though my last computer was only a couple of years old, I can tell a difference in performance with this new processor. It is lightning fast and I’m really excited to see what it can do.

I’ll post in the future to update on the frontend testing issues as progress is made!