Porting Apps to Apple Silicon: What Rosetta 2 Actually Feels Like
Developers are putting Rosetta 2 and universal binaries through their paces days after Big Sur and the M1 Macs shipped.
It’s been two days since Big Sur landed and the first M1 Macs started showing up on doorsteps, and the developer corner of tech Twitter has basically turned into one long thread about Rosetta 2. If you’ve been putting off thinking about the Intel-to-Apple-Silicon transition, this is the week it stopped being theoretical.
For anyone who hasn’t been following closely: Rosetta 2 is Apple’s translation layer that lets Intel-only Mac apps run on the new M1 chips without the developer doing anything at all. You download the x86 binary, double-click it, and macOS quietly translates it to Arm instructions either at install time or on first launch. The alternative, and the one Apple clearly wants developers to move toward, is shipping a “universal binary” — a single app package that bundles both Intel and Apple Silicon code, with the OS picking whichever one matches the hardware it’s running on.
Why this matters right now
The last time Apple pulled off an architecture switch like this was Intel itself, back in 2006, and Rosetta (the original) got a reputation for being “good enough to get by.” Early impressions of Rosetta 2 this week are more optimistic than that. People testing everyday apps — browsers, editors, utilities — are reporting that translated apps launch fast and feel close to native in casual use. That’s a meaningfully different starting point than fifteen years ago, and if it holds up under sustained use, it buys developers real breathing room to do a proper Apple Silicon port instead of scrambling.
That breathing room matters because not everything translates cleanly. Anything doing low-level system calls, kernel extensions, virtualization, or leaning on Intel-specific instruction sets is a much harder case, and Rosetta 2 explicitly doesn’t support translating kernel extensions at all. So the apps most likely to have a rough week are the ones developers were already nervous about: security tools, virtualization software, and anything with a driver component.
The universal binary path
For most app developers, the actual technical lift to build a universal binary is reportedly not huge — Xcode can produce one from existing project settings without a rewrite, assuming your dependencies also build cleanly for Arm. The harder part is dependency chains: if your app links against a third-party library that hasn’t shipped an Apple Silicon build yet, you’re stuck waiting on someone else’s timeline, or falling back to Rosetta translation for your whole app in the meantime.
It’s early days, and the sample size right now is enthusiast developers with M1 dev kits or brand-new retail Macs kicking the tires rather than production workloads under real load. But the fact that Rosetta 2 is drawing “this actually works well” reactions instead of the usual emulation-layer groaning is a good sign for how smooth this transition might end up being. I’d expect the next few weeks to bring the first real horror stories too — nobody’s compatibility layer is flawless — so it’s worth watching whether today’s optimism survives contact with bigger, messier codebases.