Two weeks ago I finally received a Mac mini M1 with the brand-new, ARM-based M1 (Apple Silicon) processor. There’s been a lot of speculation and conflicting information about its performance. I would like to talk about it in the context of web development. Just to give you an idea: it’s a monster worth every penny of its modest price.

Speculation, benchmarks and uncertainty. 

When Apple announced their plan to transition to their own processors I was equal parts excited and sceptical. Sure, they have been making their now processors for the iPhone and iPad and I have first hand experience of their amazing performance… as far as mobile devices go. These devices also have relatively spartan amounts of RAM when compared to desktop-class machines, relatively small screens and are essentially running one application at a time. Would that experience translate well to building a desktop-class processor and GPU?

Knowing that any choice I made would be final — no user upgradeable, or even accessible, parts are present on this machine — I decided to order a customised Mac mini M1 (16GB RAM, 512GB SSD) in November, as soon as the orders opened in my country. “What’s the worst case scenario?”, I thought to myself. Selling it after a few months and losing a few hundred Euros? I can live with that gamble.

In the meantime, I was looking at early benchmarks. They seemed to confirm that it’s a speedy processor. More in-depth technical analysis of the microarchitecture also hinted at a machine that is likely to perform very well despite being an ARM-based design (or exactly because it’s an ARM-based design, if we’re talking about the unheard of 8-wide decoder).

Of course, synthetic benchmarks are largely a lie when it comes to real world usage. They are an arbitrarily weighed average of arbitrary tasks that may or may not have relevance to real world workloads, trying to measure the sustained (as opposed to peak) performance of just the CPU with total disregard to how everything else in the system is tied together. So when I saw the benchmarks imply that the 1400 Euro Mac mini M1 would be in par, if not a little slower, than a 4300 Euro mid-2019 MacBook Pro 15” with an Intel Core i9-9980HK I was dubious. I thought there’s not a snowball’s chance in Hell that it’d be in the same ballpark.

I had already placed a non-cancelable, non-refundable order for my customised machine so I was just sitting here, thinking that I have either made an expensive mistake or a great decision — something which would have to be determined in hindsight.

Real world results are stunning.

Then, I received my Mac mini M1 on January 4th, 2021.

As soon as I turned it on it felt… snappy. I sailed through the macOS installation without any of the familiar “are we done yet” pauses I knew from the Intel-based Macs of yore. Installing software so so fast that I couldn’t keep up, finding the various DMGs and whatnot, instead of the Mac not keeping up with me. That was strange.

As it happened, I was in a middle of a large scale code refactor I had started on my MacBook Pro which I continued on the M1. PhpStorm felt much more responsive and enjoyable, without having to quit and reopen it every hour. Answering support tickets and emails, using the web, using Messages, all the little stuff was fast too. But just how fast is “fast”?

I decided to run my own benchmarks, timing typical workloads in my working day:

• Build the Akeeba Backup installation package from sources. This uses Phing to create Joomla installation ZIP files for each library, module, plugin and the Akeeba Backup component itself, finally placing them all in a ZIP package with a generated XML manifest. This is heavy on disk and CPU.
• Back up a medium-sized Joomla 4 site, created to mimic the characteristics of our business site (akeeba.com). It has some massive tables and tons of files, generating a backup around 380MB. This is very heavy on disk and CPU and goes through the database server a heck of a lot.
• Run the FOF unit tests suite. This is PHPUnit 5 (I know!) and half of the tests do use the database (albeit in-memory tables) — which makes them more of integration tests than Unit Tests, but there’s a reason for this madness, I promise. This is mostly heavy on the CPU and memory.
• Joomla 4 composer install with a primed package cache to rule out the network variance when downloading software. I basically run composer install on Joomla’s dev-4.0 branch, deleted the libraries/vendor folder and run it again. The second time is what gives me the timing. This is very heavy on disk, CPU and RAM. The latter two may come as a surprise to you. Do remember that Composer is a package manager. It needs to figure out the dependencies between everything installed. This is very CPU and RAM intensive.
• Joomla 4 JavaScript and CSS compilation. I decided against using npm ci because it does go through the network and introduced variable latencies, skewing the results. The JS and CSS compilation is CPU-heavy.

These are my typical workloads as a web developer. Testing and building software, running backups, using Composer, and compiling / minifying JS and CSS files.

Let’s take a look at the results:

I used the following devices:

• ZenBook: Asus ZenBook UX410U with Intel Core i5 7200U @ 2.50GHz, 24GB DDR4 2400MHz (8GB soldered on-board + 16GB SO-DIMM), on-board NVMe (PCI Express x4) SSD.
• MBP: MacBook Pro 15,1 (15” mid-2019, model A1990) with Intel Core i9 9980HK @ 2.40GHz, 32GB DDR4 2400MHz (soldered on-board), on-board NVMe (PCI Express x4) SSD.
• Mac mini M1: Mac mini M1 late-2020 with Apple M1, 16GB LPDDR4 (soldered on-board), on-board NVMe (Apple Fabric) SSD.

All machines use identical Apache, MySQL and PHP versions with identical configurations. Apple devices run macOS Big Sur 11.1. The ZenBook dual boots on Kubuntu Linux 20.04 and Windows 10 20H2. All devices have all the latest updates installed at the time of this writing (January 2021). All machines use full disk encryption at the Operating System level: FileVault on macOS, LUKS on Kubuntu, and BitLocker on Win 10.

You may wonder what the heck is going on with the unit tests on the ZenBook. I have no idea! I have noticed this huge discrepancy in the brief period I was using a Microsoft Surface Book and when Travis is running the tests in its Linux-based CI environment. I just don’t know how come macOS is so much faster. It’s also one of the many reasons I sold the Surface Book and started using a hand-me-down early-2013 13” MacBook Pro three years ago (I gave it away when I got the much beefier MacBook Pro). I can’t wait 12 to 22 minutes for a bunch of simple unit tests to run when I’m in the middle of refactoring code!

Another thing to note is that Windows is insanely slow on tasks which are heavy on disk I/O, despite using a very speedy NVMe which, according to benchmarks, is within 7% of the performance of the NVMe drives in my Apple devices. Given the amount of RAM and the information in Task Manager the disk I/O is memory cached. It’s just… Windows.

Beyond that, I’m stunned at how much faster the Mac mini M1 is for my typical web development workloads. It’s beyond belief that a machine a fraction of the price of the souped up MacBook Pro will run laps around the latter. All that without breaking a sweat. Literally. I’ve never seen the Mac mini M1’s CPU go beyond 38ºC and its fan stays at a totally inaudible, even in the dead of night, 1700 RPM. That was still the case when I was building the Docker images for my multi-PHP web development server setup (the one I mainly use for testing) which compiles a ton of PHP extensions from source. In comparison, the MacBook Pro runs at a toasty 50-60ºC and its fans are at a rather audible 2400RPM or more even when it’s doing absolutely nothing. Building the same Docker images sends the CPU to a blistering 98ºC (the thermal cutoff is 100ºC) and the fans go all the way to a loud 5000 RPM, making the poor laptop sound like it’s about to take off 

Overall feel and subjective remarks.

The M1 is not just an ARM-based CPU, it’s a SoC (System on Chip). It has the CPU cores along with a GPU, the Neural Engine (dedicated cores for Machine Learning), an image signal processor and a memory architecture which shares the RAM between all components without the need for an external bus. This is important when it comes to tasks like Photos analysing my 24G of photographs and Spotlight indexing my 10G of email and copious amounts of files. When I upgraded the MacBook Pro to Big Sur these tasks had to run from scratch and took the better part of two days during which the CPU was hogged, the fans sounded like a turbojet engine, the machine was too hot to the touch, the system was sluggish and I was cursing my stupidity for doing the upgrade in the middle of a work week. With the Mac mini M1 I forgot these tasks were taking place — and they were done in a matter of five hours, possibly less. I was too engrossed in refactoring code to notice when they were done.

Opening applications is much faster than on the Intel-based MacBook Pro. If you’ve opened an app recently it reopens in under a second. Everything feels much more responsive. Browsing the web is near instantaneous, the network speed being the only speed limit. There’s no lag anywhere, there are no spinning beachballs, there’s no fans going into overdrive. It’s quiet, cool and rapid. I haven’t experienced that since I had bought a top of the line, at the time, Pentium 3 back in 1998.

Since M1 is an ARM-based architecture it doesn’t run natively Intel (x86-64) applications. Luckily, Apple implemented Rosetta 2, an automatic translation layer which lets apps compiled for Intel to run on M1-based Macs. The first time you try to install or run an app compiled for Intel, macOS will ask you to install Rosetta 2. It takes seconds and it works amazingly well. You will only notice a ~2 second delay the very first time you run an application that needs translation. The performance is near native. I have several applications I run like that: XMLMind XML Editor, Charles Proxy, 1Password 7.1 from the App Store (I have now switched to a beta that’s M1 native), GasMask, OBS, Blue Sherpa (which installs a system extension and still freaking works), a couple games. It’s magic. It’s also funny how you can play games with pretty decent performance without a dedicated GPU and without the fans going crazy all the time — a complaint I had with the MacBook Pro. Apple’s experience in automatic byte code translation from the previous switch 15 years shines here.

The only thing you cannot run with Rosetta is applications which use virtualisation, such as Docker and VirtualBox. Well, M1 does offer a virtualisation solution but it won’t run x86 Operating Systems. I’ll come back to that later.

iOS apps on your... desktop?

A second-order effect of moving Macs to the same ARM-based architecture as iOS / iPadOS is that it’s now possible to run iOS and iPadOS applications natively on your M1-based Mac. I’m not talking about Mac Catalyst which allowed developers to create slightly different versions of their iPad applications with native Mac integrations (something Apple used to redesign and rewrite a host of first-party applications such as Messages and Home). I am talking about running the actual iPad or iPhone version of an application on your Mac desktop. At least, that’s the theory.

I had mixed results with iOS / iPadOS applications. Very few iOS apps — at least of those I use — are noted as compatible with macOS. I was able to run iVMS-4500 (a security camera monitoring app) and Keybase just fine, the latter just because I didn’t feel like installing the full fat version just to check a couple things in my account. Fight Club 5, an app I use for playing Dungeons and Dragons, refuses to go past the splash screen. All my other iPhone / iPad apps are camera apps which don’t apply, are not available on the Mac at all (developers can opt out from making iOS apps available on Macs) or didn’t make sense.

This feature is a cool gimmick with limited real world usage as far as I can tell. I appreciate the fact that I can now monitor my security cameras without having to install a clunky macOS app (iVMS-4200) that constantly crashes but that’s about it. My key takeaway from this feature and the design changes in Big Sur is that Apple is hinting towards convergence of iPadOS and macOS, making tablets more like computers and vice versa.

Isn't 16GB RAM too little?

The first crop of Apple Silicon Macs all come with 8GB RAM as a standard, upgradable at purchase time (and only at purchase time, for the RAM is part of the CPU package) to 16GB. This would have most professionals cringe and turn away in frustration. Even more so when it's by definition shared with the CPU cores, the GPU cores, the image signal processor and the Neural Engine cores.

As it turns out, 16GB is plenty, even for us who tend to run a lot of memory heavy applications. Sure enough, at some point it will start swapping. Unlike the Intel-based Macs I had used before swapping is not something I felt. I only know my Mac was swapping because I opened Activity Monitor for an entirely different reason (I wanted to check if slow access to the web was ultimately a local networking issue) and I noticed that at this point my swap was nearly 3GB. Huh.

I think that the reason I never felt it has to do with Apple's unified memory architecture and Apple Fabric, their equivalent to PCI Express which is used to connect to the NVMe-equivalent solid state drive. It's all so speedy and seamless that you are unlikely to notice unless you try really, really hard – like rendering large video streams while editing a really high resolution photo or something.

Web development tools and Apple Silicon.

Let’s get to the question I hinted to answering with this article. How practical is it to do web development work using an M1-based Mac?

In my opinion it’s very practical, even though in these early days you’re very likely to run into a few obstacles. That said, it’s astounding how within less than two months since the first M1 Macs came out we’re at a perfectly usable state of affairs.

Let’s break it down to the tools we are likely to use as PHP, Joomla and WordPress developers.

Apache, MySQL and PHP

Many of you are using MAMP to set up a local web server. You still can on an M1 Mac but you’ll be going through Rosetta 2. The performance difference will be mostly negligible, especially given the fact that the M1 is just as fast if not outright faster than a laptop-variant Intel Core i9, the top of the line processor you can see on an Intel-based MacBook at the time of this writing.

As you’ve read in my past articles I prefer to set up my own local server using HomeBrew to install Apache, MySQL and PHP. No problems there except for the fact that only PHP 7.4 and 8.0 are available through the Apple Silicon-native version of HomeBrew. If you have a reason to run older versions you can also install the Intel-based HomeBrew which gives you access to versions of PHP as old as 5.6 using third party taps. Setting up Apache to talk to PHP through PHP-FPM makes it perfectly possible to combine a native Apple Silicon version of Apache with an Intel (translated through Rosetta 2) version of PHP. I chose not to do that since I already have a Linux laptop to test with older PHP version when necessary. Moreover, I can still run older PHP versions using Docker — but I’m getting ahead of myself.

HomeBrew

As of version 2.6.0, released 1 December 2020, HomeBrew does support Apple Silicon natively. Just follow their bash-based installation and it will automatically install the Apple Silicon version on your M1 Mac.

There are some caveats documented in their GitHub issues 10152 (current) and 7857 (closed, pre-release). That is to say, some formulae don’t work with Apple Silicon just yet. There is a handy third-party reference of all formulae and their status for native Apple Silicon.

If something isn’t available natively on M1 and you really need it — such as Kubernetes CLI, Maven and other Java-based formulae like closure-compiler and yuicompressor — you can always install the Intel-based HomeBrew alongside the Apple Silicon native HomeBrew. The Apple Silicon native HomeBrew installed in /opt/homebrew whereas the Intel-based on installs in /usr/local. Formulas installed with the Intel-based HomeBrew will run through Rosetta 2.

Java

I normally install Java support on my Mac using HomeBrew. At the time of this writing the OpenJDK formula is not working yet. This means that you can’t install Java on your Mac using the Apple Silicon native HomeBrew. Likewise, trying to install any formula which depends on OpenJDK will fail.

There are two solutions. One is parallel installation of the Intel-based HomeBrew as explained above. This has the downside that you are going through the Rosetta 2 translation layer which can be a tad slower, especially for complex software such as Apache FOP (used in the workflow transforming DocBook XML documents to PDF, for example).

The second option is installing the Zulu build of OpenJDK for Apple M1. This is a patched version of the OpenJDK Java runtime to support Apple M1. It works BUT HomeBrew will still have no idea that you have installed it manually. As a result, installing any Java-based formula will still fail. You can still install and run any Java-based software manually, though.

I am currently using the Zulu build of OpenJDK to run command line Java software: Apache FOP for building the documentation of my software, Closure Compiler for minifying JavaScript, YUI Compressor for minifying some legacy CSS I haven't gotten around to rewriting as SCSS.

phpStorm

phpStorm does offer a native version for Apple Silicon. You need to install JetBrains Tools, which is still Intel-only and goes through Rosetta 2. Expand the Available for Apple M1 section and install phpStorm. Having gone through two large code refactors with it I can tell you that it’s solid as it is fast.

Git, gpg, npm

They install via HomeBrew and work great.

Composer

Unsurprisingly, Composer works perfectly. It is PHP software, after all. I am using it with the native Apple Silicon version of PHP 7.4 installed via HomeBrew. I installed Composer via HomeBrew but I am keeping it up-to-date manually.

Electron apps (Postman, Visual Studio Code, Slack, Keybase, Signal, Element, Spotify, …)

All Electron-based applications I’ve used so far are compiled for Intel. Unsurprisingly, they work fine through Rosetta 2. I generally try to avoid Electron-based apps because they chug down memory like there’s no tomorrow. At least on M1 they don’t make the fans go bonkers. Small mercies…

Design apps

I’m using Acorn for photos and bitmap graphics, Inkscape for vector graphics. Both are compiled for Intel and work great through Rosetta 2. I can’t tell if there is any kind of speed difference but I am a fairly light user anyway. Affinity has made all of its software available for M1 and Adobe is working on it.

Docker

Developers, rejoice! Docker has an Apple M1 Tech Preview version which works reasonably well. I have used it to run older PHP versions which are not natively supported on macOS under M1. Using Docker I could use the official PHP repository for PHP 7.3 FPM. 

Some images are not available for M1’s native ARM architecture but Docker can use Rosetta 2 to run them under emulation. You need to add the --platform linux/amd64 option in the command line but, hey, you don’t have to give up your Docker images. This is amazing news for many of you, I’m sure.

As for performance, it feels the same as using it natively on my i9 MacBook Pro. It's weird, knowing that there are so many levels of indirection and on-the-fly opcode translation. I guess the M1 is a really powerful beast.

BootCamp

It’s not supported on M1 Macs.

According to Apple SVP of Software Engineering Craig Federighi in his interview on Ars Technica, the Mac mini could just as well run Windows 10 on ARM... if Microsoft would change their license. Currently, Microsoft only licenses Windows 10 or ARM when it's bundled with a device by the manufacturer. Once that changes there's nothing preventing Apple from implementing Boot Camp on M1 Macs. Right now, however, there's no official route to running Windows natively or under virtualisation on M1 Macs.

Speaking of dual booting, there is currently no Linux distribution which runs on the Apple M1. Sure enough, the kernel supports ARM processors but there is no support for all the system devices in a Mac. There's a crowdfunded project which aims to add support but it's too early to tell if it will pan out. You can, however, run Linux built for the arm64 architecture under virtualisation.

Other virtualisation (VirtualBox, Parallels, VMware)

Things get a bit murky here. Apple M1 does offer virtualisation support but you can only run native ARM byte code. In other words, you cannot run Intel-based operating systems under virtualisation.

VirtualBox has not announced any plans on supporting Apple M1. Given that it’s barely being maintained since Oracle took it over I can’t say I’m surprised. 

Parallels already has an M1 preview version. You can run ARM-based Linux distributions — such as Ubuntu for ARM — and Windows 10 on ARM (if you *cough* have a license from Microsoft *cough*). The latter is intriguing because it already has emulation support for x86 (32-bit) applications and emulation support for x86-64 (64-bit) applications is currently available for Insiders. In short, you will be able to install Windows 10 on ARM on Parallels and use that to run 32-bit and 64-bit Windows applications using Microsoft’s equivalent of Rosetta 2. This may or may not be a viable alternative to Bootcamp depending on your use case. Again, it depends on Microsoft actually changing their license for Windows 10 on ARM.

VMware said on Twitter right after WWDC, when M1 was officially announced, that support for M1 is coming but they can’t commit to a timeline just yet. 

Vagrant would use VirtualBox by default which is not available on M1. Instead, you can use either the Docker provider for Vagrant (since Docker does run on M1 natively) or the VMware provider, when VMware releases an M1 version of their virtualisation software. Again, the limiting factor is that you can only run ARM-based virtual machines.

This leaves us with what I think are the top three concerns regarding virtualisation on M1:

1. You can only run ARM64 virtual machines. I am not sure how Docker manages to use Rosetta 2 to run x86-64 images under Rosetta 2 but whatever they’re doing seems to not be possible for generic virtualisation tools which try to virtualise an entire computer.
2. Everything is still in preview. If you need virtualisation which works reliably enough for production use you need to stick to machines with x86 architecture processors for now.
3. Even when everything is out of preview there’s a reasonable concern that developing on ARM and deploying on x86 may cause problems if you accidentally hit a platform-specific behaviour, limitation or bug. This will become less relevant one deployments are against ARM servers. Amazon EC2 already offers ARM-based instances and other public clouds will soon follow suite.

Should I drop my Intel computer and rush to buy an M1-based Mac?

It depends.

My experience on the M1 is that of a PHP software developer and casual gamer. In the two weeks I've had this machine I've made two massive code refactors, I've released new versions of a bunch of my software, I've played Beyond A Steel Sky, used the web a lot, Messages and Mail are basically open all the time, watched videos, listened to music and I've even compiled a few FOSS projects with Xcode (they didn't have native Apple Silicon releases yet). It's been the only machine I've been using. It's definitely the best machine I've used and I'd recommend it to myself without a second thought. But I am me and you have your own use cases. So, let's see...

If you have an old Mac from four or more years ago, or you come from the Windows world, you will enjoy the much faster and reasonably priced M1 Mac. I never thought I'd put "reasonably priced" and Mac in the same sentence. The thing is, an Intel- or AMD-based machine in the same price range doesn't hold a candle to M1's performance. So, yeah, it's still a pricey machine but it's one that outperforms most x86 machines twice its price. Reasonably priced it is, then.

If you need to dual boot Windows 10 or run x86 / x86-64 virtual machines (NOT just Docker containers which, as I mentioned, are supported just fine) you need to avoid M1 Macs. 

If your requirements mean that you can’t buy an M1 Mac you can of course still consider buying an Intel-based Mac; the transition to M1 won’t be complete before the end of 2022, per Apple’s WWDC keynote. They said they will support Intel-based Macs “for years to come”. Extrapolating from their last architecture transition, from PowerPC to Intel in 2005, that gives you a reasonable 4-5 years of support, at which point you would contemplate upgrading anyway.

If you have a fairly recent Mac, a 2017 or newer model, you should probably hold off for now. Your Mac is no slouch and you can expect a few more years of updates. Besides, M1 seems like a first small step. It’s Apple proving to Intel that its M series processors not only have a low TDP (thermal design power) but can also offer performance that puts Intel’s top of the line laptop CPUs to shame, not to mention that their GPUs are far better than anything Intel has offered to this date.  I suspect that the next step is an M series processor with a higher TDP for machines with a higher thermal budget — such as the iMac and Mac Pro product series — therefore taking on Intel’s Xeon processors. 

After I wrote the paragraph above and before I started proof-reading it, Bloomberg ran an article about Apple's plan to release a new iMac and a new Mac Pro with the next generation of Apple Silicon processors. If only I had published this blog post a couple days earlier, I wouldn't sound like a prophet after the fact. Ah, well...

Beyond the Apple ecosystem, Qualcomm is working on desktop class ARM-based System-on-Chips. The Qualcomm 8cx architecture beat Apple M1 to the market by two-odd years but it was a bit ahead of its time (nobody really understood why on Earth you’d want to use ARM instead of x86 on something that’s not a mobile phone, tablet or Internet of Things device) and had a relatively lukewarm performance compared to laptop-class Intel CPUs. Yet, Qualcomm feels that Apple M1 validates their decision to work with Microsoft on Windows 10 on ARM. It’s very likely that we’ll soon see non-Apple laptops sporting ARM processors. If you’re not already invested in the Apple ecosystem and don’t have a pressing need for a new machine it may be a good idea to hold off and see how it plays out in the next two years. 

In conclusion.

In my opinion, Apple’s insistence of building the whole widget delivered an absolute gem of a machine. I am happy with my decision to buy the Mac mini M1. It’s a great little machine for me, with plenty of horsepower to get me through my working day and beyond, staying cool and quiet no matter what I throw at it. I can now relegate my MacBook Pro to out of office use — whenever it is that we can safely get out of our houses again.