M1 MacBook Air Review
As many developers know, compiling code takes a lot of processing power, especially if the codebase in question is rather large. We have a fairly large codebase. It contains about 800 Objective-C classes, 2200 Swift files and about 600 storyboards. All in all, about 700 MB worth of raw source code and assets.
Some of our team members use the latest 2019 MacBook Pro. Our team also employs a couple of Late 2013 “trashcan” Mac Pros as build servers. The MacBook Pro has an Intel Core i9 CPU (8 Cores @2.3 GHz), coupled with an AMD Radeon Pro 5500M GPU, 16 GB RAM and 1 TB SSD. Each build server is powered by an Intel Xeon E5 CPU (6 Cores, @3.5GHz), 2x AMD FirePro D500 GPUs and 16 GB RAM. These are by no means slow machines, but we could do with an upgrade.
Recently I’ve had the privilege to test drive Apple’s latest M1 equipped MacBook Air.
On paper the 2019 MacBook Pro performs 30% better than the 2013 Mac Pro. That same paper shows the new M1 should have 63% better single core and 16% better multi-core performance when compared to the 2019 MacBook Pro. The Air obliterates the 2013 Mac Pro on paper. More than 2x the single core performance and 1.5x the multi-core performance. However, benchmarking scores are not always a true reflection of real world performance. So I was sceptical when I saw the numbers.
In order to see the new Apple Silicon M1’s real world performance, I took our codebase and compiled it over and over and over on the M1. I used the machine as my daily driver for 6 days and compared it to our current hardware. I wanted to see if it could keep up with “pro” machines.
The Mac Pro compiles our app in about 5 minutes; a very respectable build time for 8 year old hardware. The MacBook Pro is a little bit faster, clocking in at just over 3 minutes, until the Core i9 CPU heats up and starts to throttle itself. Once the i9 reaches 90°C, it slows to a crawl. Once the fans start spinning, the MacBook Pro’s build time falls to nearly 7 minutes on a good day, provided you only have Xcode open. With more applications open, build times on the MacBook Pro falls to 10 minutes, and on a hot day, 15 minutes.
The M1 MacBook Air has 8 cores (4 high efficiency, 4 high performance), 8 GB RAM, 7 GPU cores, a 16 core Neural Engine and 256 GB on-board storage. The Air only supports one external display and only has 2 USB 4 ports. The screen is small, the battery is tiny, the FaceTime camera is terrible, there is no fan or active cooling system, and the Air weighs just over 1 kg. In simple terms the machine is the under powered entry level MacBook Air one would typically recommend to your grandmother when she wants an easy to use laptop that can do the Google, visit the Facebooks and view the Exchange-a-grams.
With all that being said…
WOW!
I honestly did not expect this kind of performance from a MacBook Air! I am lost for words.
WOW!
The M1 powered MacBook Air is super fast when compiling our codebase. It flies through our files, opens storyboards in a flash and boot times are practically non-existent. The M1 can compile our large codebase in just over 2 minutes. Yes, that’s right. Just over two minutes. Every time. Looks like the paper did not lie!
The Rosetta 2 translation is incredibly fast and transparent. Running x86 and ARM based apps side by side is extremely smooth. I could not see any obvious performance difference when an app was running under Rosetta 2. Running iPadOS apps and games on the Air was also an incredible experience.
The M1 MacBook Air never gets warm, no matter how hard I pushed the machine. The only two parts that showed any sign of heating up was the Anker USB-C to HDMI adapter and the Air’s power brick.
Battery life is also excellent. The Air managed to stay alive for a whopping 5 hours while I constantly compiled code on it. For perspective, the 16” MacBook Pro barely survives for two hours on battery life when I actively work on it. When not using Xcode, I’ve gotten about 12 hours of screen on time, the 16” MacBook Pro has never lasted longer than 5 hours.
However, it’s not all rainbows and sunshine. Multi-tasking is a serious issue. The M1 struggles with multitasking. Running Xcode, Teams and Outlook is fine. Screen sharing via Teams while compiling code and reviewing designs on Zeplin is not fine. The Air slows down so much, audio playback starts to lag. Opening and compiling two instances of our codebase can pull the machine to its knees.
The MacBook Pro is a lot better at handling multiple tasks; unfortunately, it runs really hot. CPU temperature is constantly over 80°C, causing the CPU to dip to just over 1 GHz when pushed to its limits, but its still better than the M1 because the machine still stays usable. The MacBook Pro is no where near as good as the Mac Pro when it comes to multitasking. Although the Mac Pro took 5 minutes to compile the app, it was able to compile 4 copies of the same project in the same time frame. The E5 was designed to handle multiple work streams simultaneously, 24 hours a day, 7 days a week. The Mac Pro’s CPU never dipped below 3.5 GHz, even when it heated up to 85°C. This is where the Mac Pro’s strength lies. It’s not the fastest machine on paper, but it can handle the most load.
I suspect that the Air struggles with multi-tasking because it only has 8 GB RAM and only 4 high performance cores. Our codebase consumes about 6 GB of RAM on a good day, Microsoft Teams & Outlook eats another 1 GB each and Zeplin will chew away a good 4 GB when reviewing large designs. No machine with just 8 GB RAM can deal with this level of memory demand. At one point the Air had almost 10 GB swapped to the disk. I think the 16 GB RAM upgrade would definitely be worth the money.
Our Android friends won’t (yet) be the new M1’s biggest fans either. While Android Studio works fine and can compile their code fine, Its not as smooth as Xcode. Android Emulators are also out for now as they rely heavily on Intel’s virtualization process. Obviously, the M1 does not support this. Hopefully in time Google will update Android Studio and the emulators to work on the new M1. Luckily, Microsoft recently added M1 support to their tools, so there is hope.
As an iOS developer, I’m genuinely impressed with the little M1 MacBook Air. But, the drawbacks do not (yet) outweigh the benefits for me. The 2019 16” MacBook Pro has more cores, more RAM and can handle more demanding tasks better. Yes, the 2013 Mac Pro is slower than the M1 chip, but it is a beast of a multitasking machine.
In conclusion, the new M1 MacBook Air is a small, sleek, light little powerhouse of a machine. Despite the fact that this is not a “pro” machine, its a great developer tool, even if you’re working with a large codebase, provided that you don’t need to do too many things at once.
If you need a workhorse that can deal with multiple workloads, stick to real Pro machines, like the 2013 Mac Pro. The 2019 Mac Pro is even better! If you need a portable Mac that can handle a semi strenuous workload fairly well, stick to the 2019 MacBook Pro. If you only need to work on one thing at a time, give the new MacBook Air a try. If you need a portable workhorse that can deal with demanding tasks 24/7, wait for Apple to release an updated MacBook Pro with an Apple Silicon chip.
I’m really excited to see the “pro” version of the M series chip that supports more displays, more RAM and can handle more tasks at the same time. If the M1 is the starting point, I cannot wait to see where Apple is heading with their new Silicon!
Disclaimer:
Testing was done using our proprietary iOS codebase. All machines were running macOS Big Sur 11.2.1 while using Xcode 12.1 to compile code. Benchmarking scores were calculated using Geekbench 5 with no other applications open and no other hardware connected. All portable machines were charged to 100% and plugged into a power outlet while performing tests (except the battery life tests). Battery life tests started with the battery at 100%. All machines were located on a flat surface with optimal airflow around the machine’s vents and in the same room with an ambient temperature ranging from 23°C to 30°C. CPU temperature was gathered using the Intel Power Gadget app. All derived data was cleaned before and after each compilation. Testing was done with only Xcode open with no additional hardware connected unless stated otherwise. Code was only compiled. Time was calculated using Xcode’s internal build timer. No other security measures were applied at the time of compilation. Archiving tests were not performed as special licences were required to apply compile time protections.
