Current State of M1 Macbooks for Developers

Subscribe with RSS

I'm sure everyone has heard plenty about the excellence of the M1 Macbooks (I have an Air, by the way; a fanless ultraportable with that kind of performance really attracted me), so in the beginning of this post I will stick to pain points and quirks I experienced with the Macbooks and how I solved them (if I could) to serve as a reference for others, leaving the fairly generic "wow m1 good" at the end.

the tl;dr judgement is: for most developers, it's going to be 95% of the way there by now. If you know what you're doing, you can fill that 5%. If you don't, you might have some frustrating googling ahead.

App Compatibility

I'm sure everyone has heard enough of how the M1's seamless ability to run x86 applications, but it really has to be said that it's hard to tell that you're running a program that's not in the devices native architecture.

Almost too difficult to tell. I really wanted to make sure I ran everything native that I could - and honestly sometimes it was hard to tell if I was downloading the native or emulated version. Package files don't seem to say if they're universal binaries, so you have to extract them first. I suppose this is not something Apple wants, but I wish there were an easier way to tell if an application was native or not.

This database is a good reference. As a side note, it also seems to have awful SEO - I consistently get articles ABOUT the page rather than the page itself.

In any case, my two main languages for my personal works are python and rust. Here is the compatibility status of my most used applications


* The stable release of VSCode is not native, but the "Insiders" release is.

Very recently true: Homebrew is native now!

Note that, somewhat ironically, most of the applications that are not native are electron apps - they'll likely gain an M1 native version when they eventually update their electron version (I can understand why that would be more of a challenge than it seems), but it is strange having Chrome work natively but not the apps that depend on it.

For Spotify and Discord, I actually currently run them as Chrome webapps (shortcuts->launch as window). Works fine, since I'm a fairly light user of both. I did try them as translated, but there were some graphical hitches on Discord (although I seem to be alone on that), and why run translated stripped down Chrome when I'm already running native Chrome?

I have to say, though, Spotify and Discord are all the more disappointing because they also disabled the iPhone clients from being used on Apple silicon. Especially for Spotify - the iPhone version would be perfectly fine for my use case and probably run better to boot!

Slackdoes have an M1 native version. And so does VSCode. So it seems (as you'd expect) there's no technical reason why the electron apps don't have native versions.

The other major exclusion is Dropbox (yes, I'm apparently one of the few people that still subscribe to dropbox), although it seems to be in the works.

Mouse Issues

I'm not sure if this was just a weird issue with my specific peripheral configuration or what, but disabling mouse acceleration also crippled the sensitivity of the mouse - so much that even at max DPI on MxMaster, it was still too slow. If you moved the sensitivity in settings, it would re-enable mouse acceleration.

I fixed this in the end with SteerMouse, which allows you to modify the acceleration and sensitivity separately, but I remember that the good ol' defaults write .GlobalPreferences -1 would not have this behavior. Probably a Big Sur behavior, rather than an M1 thing, but I'm a little surprised to never see this mentioned. Maybe more people use mouse acceleration than I thought? Am I the weird one?

In the Wild


There were some rough edges. For instance, many of my projects are in python and use postgresql, so I have psycopg2-binary as a dependency on many of them. While running pipenv install (yes, I use poetry now, but some of them predate that and I don't care enough to switch them) I received some linker errors.

Here's a github issues thread on it

In my case, linking openssl fixed it. psycopg2 is popular enough that there were other users having the issue and finding solutions, but it's possible that less used packages, especially ones that have to interface with native code, rather than be pure python, would have issues.

Another python issue came with PyQt5. Trying to install it caused this error

hook = backend.prepare_metadata_for_build_wheel
AttributeError: module 'sipbuild.api' has no attribute 'prepare_metadata_for_build_wheel'

With an ugly traceback accompanying it. This led me on a wild goose chase with pyqt5-sip, and Googling the error led to no useful outcomes - just people recommending others to upgrade pip.

Turns out, the actual issue was that qmake wasn't in my path. It is building it from source, I suppose? But what a stunningly unhelpful error. The M1 related issue is that the platform is too new for there to be wheels for PyQt5, so it had to built from source. The rest is the python packaging being an idiot.


On the rust side, well, Cargo seems to just compile everything from source anyway, so there's no issues here (although, if you'd believe it, the build directory for this blog, between debug and release, is almost 5 GB in size).

Flutter (and Android)

I was shocked how easy it was to get the Android toolchain set up. It's running in translation, but I only know that because I checked the binary afterwards. You just install it, and it works, and Flutter has no issues interfacing with it.

I had to use the beta channel of flutter - before then I was hanging on a gradle build - but otherwise this is a stunningly complex chain of technologies and it all works perfectly. I had a flutter app running on my physical Android device. Of course, there is no issues with the iOS toolchain.


I'll admit I'm not a super heavy user of Docker, but it is the elephant in the room. It's released under a Technical Preview (and considering how stable the intel release of docker on MacOS is that's fairly foreboding)... but it seems to work?

Of course, with ARM containers. I believe x86 containers technically can run through QEMU, but boy that is another level of unstable. I think whether or not this is okay will depend on your use case. For me, mostly working on small servers with languages like python, it's fine.

It does break the "contract" that your local and prod environments were virtually the same; the ARM container may not work in the same way as your prod environment. And for some that will be a dealbreaker. You'll have to decide here.

The tl;dr seems to be that for more fragile packaging systems, platform binaries for Apple Silicon have not yet been made in many cases, so they must be built from sources, and that can cause issues that other users don't expect. Be aware of that, although it will surely get better over time. And by that I mean Python, since it was where I had by far the most issues, although all were resolvable so far.

A Note on Vertical Stands

I have a vertical clamshell stand for the first time, since I am no longer afraid of the device's thermal performance. However, I did have one hitch. it's very natural with the Air's wedge shape to put the back of the wedge into the stand, however, if you have a stand that's fully metal, and you center it, the stand can cover up the device's wifi antenna.

With the unibody metal chassis, you need somewhere to stick the wifi antenna, and on modern macbooks that's here

on the back, around where the hinge is. I had quite bad wifi performance until I changed this which mystified me for a bit. Just place it in a different orientation (or get a stand that's more airy) and it'll be fine.


The performance is as lovely as everyone has said it is. I did two hours or so of chrome browsing, which reduced the battery by all of 1%. It's icey cold the entire time, too. Surprisingly a big deal when you actually have it on your lap.

The first day I had it, it was just okay - about what you'd expect from a laptop with a powerful CPU. But after a day, and all the first-launch processes like spotlight indexing, OS updates, and so forth finish running, it's noticeably smoother in operation. Especially small things like having the display turn out, changing the resolution, moving windows around. I'm not even sure specifically what causes this; perhaps improvements with the integrated GPU instead?

It really cannot be overstated how cool it runs. The USB-C dongle that is attached to it runs hotter than the chassis of the laptop even after some ostensibly expensive task, like when I compiled Qt5 from source.

Clamshell mode is a game changer too. Never has a clamshell mode worked so well; I rarely used it before because I would always need to manually press the power button, or use the keyboard and touchpad built in whenever it inevitably bugs out. But it just works on the new M1. This is by far the best "laptop-as-desktop" experience I've had.

I really think the Air is the best for developers for now; you get an actual function row, you really don't notice any performance decreases because, other than long from-scratch compiles, the developer workflow is very bursty and not about sustained performance. And you reap the benefits of having no fan; there are zero moving parts in this laptop.

Perhaps the rumored 14'' Pro will change that for those that need more performance (especially RAM), but honestly it is perfectly fine for my purposes.

But so it's been good on the Air, and with most the kinks worked out on my setup, I'm enjoying the benefits, and man are those benefits great.