I’ve been using Apple computers since their CPUs had PowerPC architecture. I experienced the transition to Intel, I saw the evolution of Xcode since its early versions, I used Rosetta when it used to run PowerPC binaries on Intel CPUs. That’s why when I saw Apple announcing it would be switching to a new ARM-based architecture, I couldn’t ignore it. It was kind of…life-changing.
Quite recently I got my first MacBook with M1, and in this article I’m going to share my experience with you.
Worries and Expectations
Apple Silicon (the current model is M1) is a mobile processor. If you have an iPhone or iPad, you probably have something very similar. And this was my first worry — Is the new MacBook (or other Mac products) with M1 is just an iPad with macOS? Or is it a full-scale computer capable of running many parallel applications, connecting multiple peripherals, etc.?
My second worry was the young age of the architecture. Intel-based desktop computers have existed for dozens of years now, so when Apple introduced the transition to Intel, it didn’t look so crazy. On the other hand, transitioning to ARM architecture could be really risky. We don’t have any guarantees that the software will be ready for it, we can lose old software, some of it may have bugs running through Rosetta 2 (Intel to ARM converter). All the Microsoft ARM-based computers weren’t successful after all.
And my last worry related to the architecture itself was about the standard politics of Apple regarding older devices. When Apple switched to Intel from PowerPC, they also introduced the Rosetta converter (first version), they also said it would be fast and smooth. And it was true for the most part, but several years later all PowerPC Macs turned into pumpkins. Apple always does everything possible to force developers to support the newest devices (and I agree with it) and drop support of older devices (which is a very bad thing for the owners of such devices). This means that in several years Apple will probably drop the support of Intel, deprecate Rosetta 2 and force everyone to switch to the new Apple Silicon architecture. And all our old Macs will turn into Windows (or Linux) computers.
As I said before, I had my fair share of worries, but also expectations. Let’s go over them and see if they were fulfilled or not.
First of all, Apple is a company with a reputation to live up to, with a big amount of users and with shareholders expecting the company to grow. Each transition has been successful so far. Would you change back to PowerPC? I doubt.
iPhones and iPads play and stream videos, run games (including 3D games) they never heat, they don’t require coolers and their batteries live longer than Intel-based computer batteries. It would make sense to expect ARM-based computers to inherit these properties.
Let’s start with Xcode as it’s a core application for macOS and iOS development. Luckily for M1 users, all Apple software was adapted for the new processors. And even better, they include binaries for both architectures. By default, Xcode runs in M1 mode, but you can change it to Rosetta 2 if something doesn’t work.
I don’t write apps for macOS, so I can’t test it, but iOS development works fast and smoothly. When running apps on Rosetta 2, on the other hand, they run with bugs. Storyboard editing often fails. Why would you run it? When I try to export AdHoc build, it fails. It doesn’t depend on the app. I guess the problem is in app thinning — it shows an error when it’s ready to offer thinning options. Xcode running through Rosetta 2 doesn’t have this problem.
Another problem is running apps in simulators. Some libraries (OneSignal, for example) can’t make a build for the ARM-based Simulator, at least old versions of them (note that by the time you read this the problem may have been solved already). So far I haven’t been able to run apps with OneSignal on Simulator without Rosetta 2. An alternative solution is running iOS apps directly on macOS, which was impossible before.
Generally, native ARM Xcode works very well. I’m sure problems will be solved soon and within a year or two all popular libraries will adapt and Xcode itself will never need Rosetta 2.
CocoaPods is a popular dependency manager. Almost all libraries on github support CocoaPods. It doesn’t work on ARM natively because one of its dependencies doesn’t. Fortunately, we don’t need high performance and we can use Rosetta 2:
arch -x86_64 pod install
arch -x86_64 pod update
Visual Studio Code
It can be different now, but at the time I wrote this, VS Code supported M1 only in Insiders Preview. I use it, and I don’t see major bugs. Plugins mostly work.
Generally, Visual Studio Code is not a very resource-consuming app, so the Intel version working via Rosetta 2 is good as well.
This has been a big source of pain for me for several months. There’s no official ARM version of it and looks like it’s not going to appear any time soon. Work is ongoing to make it happen, so sooner or later we’re going to get it. The Intel version is extremely slow. It gets stuck while typing, autocompletion fails and the simulator doesn’t work at all. There’s a beta version of the simulator for M1, but considering that new Macs usually have 8 Gb of memory, it’s easier to use an Android device.
Recently, I found an unofficial version for M1:
This is a unofficial canary version of Android Studio Arctic Fox on the Apple Silicon. (e.g M1 Chip) You can download…
It’s a very early build, so many plugins don’t work. But editing is way smoother and the basic Android Studio functionality works just fine.
Android Studio vs Xcode
An interesting observation that I made analysing the performance of different development environments — an app can work slowly in two cases:
- it needs more computational power (better CPU)
- it needs more memory
Xcode uses more CPU and on peak of activity it uses about 100% of CPU, but it doesn’t require even 8 Gb of RAM. Android Studio, on the other hand, doesn’t use all CPU power, but it consumes all the memory and it activates cache.
Note: SSD is a weak point in the new Macs. It’s really fast, much faster than it was before. But as the most popular model has only 8 Gb of RAM, which is not much for developers, it actively uses SSD for caching. It’s so fast that it may be seamless for users, but it uses valuable SSD writing cycles. Many developers, including myself, report that every month SSD looses 1–2% of its resource. The solution is to get a Mac with 16 Gb of RAM and more native ARM-optimised apps.
All JetBrains tools have native versions for M1. If you use IntelliJ IDEA, CLion, WebStorm, AppCode or other JetBrains apps, you’ll get fast and stable versions. For several months there were different versions available — you could choose Intel or ARM. Since version 2021.1.1 all apps work on ARM.
Note: Android Studio is based on IntelliJ IDEA, but it still doesn’t officially support M1. Not natively.
Intel vs ARM apps
If new Macs successfully run both Intel and ARM apps, does it make sense to choose ARM? Or will Intel do?
The answer is pretty straightforward: Rosetta 2, being an awesome tool translating apps from Intel to an absolutely different architecture as ARM is, can’t make a perfect work. Even if you get full functionality, the performance will still be worse.
Which apps are optimised for M1?
If you work with graphics, Affinity Photo and Affinity Designer can be a good choice. They are both optimised for M1, unlike Adobe Photoshop and other Adobe tools.
These apps have native versions:
- All preinstalled Apple apps
- Safari and Google Chrome
- Sequel Ace
- Canary Mail
These apps work through Rosetta 2:
- Commander One
- Most games
If you’re considering buying a new Mac, you should definitely consider a model with the new M1 (or newer) processor. The only exception I see is Android Development. If that’s your main occupation, you’d better wait for a little while.
In 2021the necessary amount of memory for developers is 16 Gb, especially if you use apps running through Rosetta 2. Having 512 Gb (or more) SSD is also a good idea as there’re only 2 USB (type C) ports in current models, and using external SSD is complicated.