Six Weeks on M1: The iOS Engineering Verdict

Apple shipped the M1 Macs on November 10. I have been running an M1 Mac mini as my primary iOS development machine for six weeks. The verdict is the one I predicted at WWDC in July, with one surprise: the transition is more aggressively complete than I expected, and the iOS engineering case for refresh in 2021 is sharper than I would have argued at WWDC.

The build is noticeably faster. The fans, when there are fans, do not spin up. The tools mostly work. The tools that do not work mostly run under Rosetta 2 at a performance level you do not notice. The case for moving every iOS engineer on my team onto Apple Silicon in 2021 is the strongest hardware-refresh argument I have seen in mobile in the last five years.

I want to walk through what's holding up, what isn't, and what the planning conversation should look like at every mobile org going into 2021.

What the discourse landed on

The mainstream-Apple-press verdict consolidated quickly. John Gruber's November 17 review of the M1 Macs is the canonical statement. The line everyone quoted: "I've never once heard it in an entire week. Never. Not once. Not a whisper." About the MacBook Pro fan, under sustained load. The other Gruber line that traveled, which matters more for our work: "apps compiled for Intel run faster in translation on the M1 than they do on actual Intel CPUs in MacBook Airs and most MacBook Pros." Rosetta 2 is faster than Intel native on x86 binaries. That should not be possible. It is.

Jason Snell's Six Colors review the same day called all three M1 machines "among the fastest Macs ever made" with the honest caveat that the fan-free MacBook Air will eventually throttle under sustained load. The throttling is real on the Air. For an iOS engineer running a single Xcode build, you will not hit it. For an iOS engineer running a build server, you will, which is part of why the Mac mini is the right M1 for desk use right now.

The benchmark that anchored the iOS engineering conversation was Matthew Panzarino's TechCrunch piece, which built WebKit on the M1 lineup. The numbers: M1 13" MacBook Pro built WebKit in 20 minutes 43 seconds. The 2019 Intel 13" MacBook Pro built the same code in 46 minutes 10 seconds. The fan-free M1 MacBook Air came in around 25 to 26 minutes, within five minutes of a 2019 Intel Mac Pro. Battery life on the M1 MacBook Pro after the WebKit build: 91% remaining. Battery life on the Intel 13" MacBook Pro after the same build: 24%.

This is a C++ build, not a Swift / Xcode iOS build, and I want to be honest that the iOS-app-specific clean build numbers are not yet in the public record as of mid-December. The community is extrapolating from WebKit and Geekbench. The extrapolation is going to be roughly right, but the precise iOS-app numbers will land in early 2021 once teams have had time to publish.

Michael Tsai's mid-November aggregation of Rosetta 2 quality is the developer-tooling read. The community converged on Rosetta running at roughly 70 to 80 percent of native speed, which means an x86 tool under Rosetta on an M1 is still faster than the same tool native on the previous-generation Intel MacBook Air. Chris Randall (Audio Damage) reported audio plugins indistinguishable from native. CrossOver and Wine 32-bit and 64-bit through Rosetta 2 working as expected. The Rosetta tax is real and almost always invisible.

When Gruber, Snell, Panzarino, and Tsai all converge in the same week with consistent framing, that is the moment to take the discourse seriously. By mid-November the verdict was "step change, not iteration," and the contrarian voices (Patrick Moorhead writing in Forbes, who Gruber responded to on December 2) had retreated to "software, not silicon" critiques that Gruber dispatched within a week.

What I actually see in practice

Specifics, with the caveat that my codebase is one large iOS app and these numbers are qualitative rather than published.

The Xcode build on my old 16-inch Intel MacBook Pro from 2019 (i9, 32GB) was something I scheduled around. Kick it off, get coffee, hope the laptop did not thermal-throttle. Fans audible across the room. The M1 Mac mini (the high-spec one, 16GB) builds the same target noticeably faster (a meaningful fraction of the Intel time, though I'm not going to publish precise numbers from an internal codebase) and is silent the entire time. The fans, when they spin up at all, are inaudible from arm's length. The thermal envelope of the Mac mini is far larger than the MacBook Air's, which is why the mini is the right M1 for a desk-bound iOS engineer in 2020.

The iOS simulator change is the part that surprised me. On Intel, the simulator ran an x86 slice of the app, which meant a different binary from what shipped to devices. On Apple Silicon, the simulator runs the arm64 slice the device runs, which is both architecturally cleaner and noticeably faster in practice. Apps launch in the simulator at speeds I had not seen on Intel. UI tests that took five seconds to start on the Intel laptop start in roughly half that on the M1 mini. The cumulative effect across a day of iterative development is substantial.

The dev loop, end to end, feels different. The "kick off build, get coffee" rhythm I had on the Intel laptop is gone, because the build finishes before the coffee. That is a small change per build. It is a large change in cumulative attention budget across a day, and the engineers on my team who have moved to M1 have noticed within their first week.

The tooling tax, mostly absorbed

The places it still hurts in December 2020:

The Ruby ecosystem. CocoaPods is the most common pain point. The ffi gem and several others have not yet shipped native arm64 builds. The workaround is arch -x86_64 to force the entire Ruby stack into Rosetta. This works but feels wrong, and the workaround documentation is scattered. Expect this to be cleaned up in Q1 2021.

Homebrew. Homebrew is mid-port. The arm64 native version installs under /opt/homebrew and the x86 Rosetta version installs under /usr/local. Most M1 setups end up with both installed, dual-prefix, with one or the other taking the path priority depending on the shell config. The dual-prefix pattern is going to be the standard for the next twelve months at least. It works. It is annoying.

Docker. Docker for Mac on arm64 is not shipping a native build yet. The community has workarounds. If your iOS engineers depend on Docker for their inner loop, this is the most uncomfortable part of the M1 transition right now. The teams I have heard from are running Docker on a separate Intel machine in the meantime.

Some pre-built XCFrameworks. Any framework that ships as a binary and has not been rebuilt for arm64 will fail to link against an M1 build. The long tail of older SDKs (analytics SDKs from acquired startups, ad networks that haven't shipped updates in a year, niche third-party libraries) is real. The vendors who care about iOS are mostly through the transition. The vendors who don't are not, and finding them is your problem.

A long tail of CLI tools. Custom build scripts, CI helpers, Ruby DSL tools, internal command-line utilities. Most of these work under Rosetta. Some of them don't because they shell out to other tools that don't. The cumulative cleanup is real but bounded.

None of this rises to "don't ship M1." All of it is annoying, and the cumulative pain is a real cost of being an early adopter that needs to be absorbed by the platform team, not the product engineers.

The fleet refresh argument for 2021

For mobile platform leaders thinking about 2021 hardware budget, the case is clean.

The savings per engineer per day are real and measurable. A back-of-envelope: roughly twenty minutes a day of build-time saved per engineer, at typical fully-loaded engineer-hourly rates, pays back the cost of an M1 Mac mini (around $1,500) in a small number of weeks at the individual level. At a team level the payback is faster because the toolchain learning compounds. Even with conservative assumptions, the math is on the engineering side of the conversation.

The qualitative win is larger than the quantitative one. The "build is silent and finishes before you noticed" effect is a productivity win that doesn't show up in any benchmark. The engineers on my team who have moved to M1 report fewer context-switches during a workday, because the laptop is no longer the constraint on iterative speed.

The right play for a 2021 fleet refresh, in priority order, with explicit budget for the toolchain hedge:

Refresh the most senior iOS engineers and the platform team first. Seniors do the most full-app rebuilds and the most complex CI investigations. The platform team needs to be ahead of the product engineers on Apple Silicon so they can solve the CocoaPods workarounds, Homebrew dual-prefix decisions, and CI architecture questions before product engineers hit them. Concentrate the Apple Silicon hardware on this combined population first.

Plan the CI architecture transition for Q2 2021. Cloud CI on Apple Silicon is still rare and expensive in late 2020. The big providers are catching up. Plan for split-architecture CI through mid-2021, with full arm64 CI by end of year.

Calibrate the laptop vs. Mac mini choice by work shape. The MacBook Air is genuinely amazing and the fan-free build experience is the launch's most surprising win, but the Air is thermally constrained for engineers doing all-day heavy builds. Give the Air to engineers whose work is meeting-heavy. Give the Mac mini or the M1 MacBook Pro to engineers whose work is build-heavy.

Budget the long-tail toolchain cleanup explicitly. Plan for a meaningful slice of platform-team hours over Q1-Q2 2021 going into Rosetta workarounds, Homebrew duplications, Docker workarounds, and XCFramework arm64 updates. If the refresh memo doesn't include this line item, the CFO's first follow-up question is going to be "what about the toolchain risk?" and you need a budgeted answer.

Where I land

The M1 is the most important iOS engineering hardware shift since the 2015 MacBook Pro. The chip delivers what the WWDC announcement promised and the early benchmark community has documented in real time. The tooling story is mostly there. The remaining gaps are bounded and being closed on a visible curve.

For mobile platform leaders, the 2021 budget memo writes itself. Refresh on M1. Start with the senior engineers and the platform team. Plan for the toolchain cleanup. The teams that do this in Q1 will look prescient by Q3. The teams that wait are going to spend 2021 watching their best engineers move to companies that figured it out first.

This is the year. Refresh.