<p>The excitement around Apple’s new M1 chip is everywhere. I bought a MacBook Air 16GB M1 to see how viable it is as main development machine – here’s an early report after a week of testing.XcodeXcode runs FAST on the M1. Compiling the PSPDFKit PDF SDK (debug, arm64) can almost compete with the fastest Intel-based MacBook Pro Apple offers to date, with 8:49 min vs 7:31 min. For comparison, my Hackintosh builds the same in less than 5 minutes.One can’t overstate how impressive this is for a fan-less machine. Apple’s last experiment with fan-less MacBooks was the 12-inch version from 2017, which builds the same project in 41 minutes.Our tests mostly ran just fine, although I found a bug specific to arm64 that we missed before, as we don’t run our tests on actual hardware on CI. Moving the Simulator to the same architecture as shipping devices will be beneficial and will help find more bugs.Testing iOS below 14 is a major problem. It seems WebKit is crashing in a memory allocator, throwing EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) (Apple folks: FB8920323). Performance also seems really bad, with Xcode periodically freezing and the whole system becoming so slow that the mouse cursor gets choppy. Some Simulators even make problems on iOS 14, such as the iPad Air (4th gen) which still emulates Intel, so try to avoid that one.We were extremely excited to be moving our CI to Mac Mini’s with M1 chip and are waiting on MacStadium to release devices, however it seems we will have to restrict tests to iOS 14 for that to work. With our current schedule, we plan to drop iOS 12 in Q3 2021 and iOS 13 in Q3 2022, so it will be a while until we can fully move to Apple Silicon.There is a chance that Apple fixes these issues, however it’s not something to count on – given that this only affects older versions of iOS, the problem will at some point just “go away”.DockerWe use Docker to automate our Website and load environments for our Web and Server PDF SDKs. Docker posted a status update blog post about the current state of things, admitting that it currently won’t work but that they’re working on it. There are more hacky ways to use Apple’s Hypervisor to run Docker container manually, however this needs arm-based containers.I expect a solution in Q1 2021 that runs arm-based containers. We’ll have to do some work to add arm-support (something already on the roadmap) so this is only a transitional issue.VirtualizationTo test our Windows PDF SDK, most folks are using a VMware virtual machine with Windows 10 and Visual Studio. Currently none of the Mac virtualisation solutions support Apple Silicon, however both VMware and Parallels are working on it. I do not expect Virtualbox to be updated anytime soon.I expect that eventually we’ll be able to run ARM-based Windows with commercial tooling. Various proof-of-concepts already exist. Microsoft currently doesn’t sell ARM-based Windows, so getting a license will be interesting.ARM-Windows can emulate x86 applications, and Microsoft is working on x64 emulation, which is already rolling out in Insider builds. In a few months, it should be possible to develop and test our Windows SDK with Visual Studio on M1 in reasonable performance.Running older versions of macOS might be more problematic. We currently support macOS 10.14 with our AppKit PDF SDK and macOS 10.15 with the Catalyst PDF SDK, both OS releases that require testing. It remains to be seen if VMWare or Parallels include a complete x64 emulation layer. This would likely be really slow, so I wouldn’t count on it.Lastly, 16 GB RAM just isn’t a lot. When running parallel tests, the machine starts to heavily swap and performance really goes down the drain. This will be even more problematic with virtual machines running. Future machines will offer 32 GB options to alleviate this issue.Android StudioIntelliJ is working on porting the JetBrains Runtime to Apple Silicon. The apps currently work through Rosetta 2, however building via Gradle is extremely slow. Gradle creates code at runtime, which seems a particular bad combination with the Rosetta 2 ahead-of-time translation logic.I expect that most issues will be solved by Q1 2021, however it will likely be some more time until all Java versions run great on ARM. A lot of effort has been put into loop unrolling and vectorisation, not everything there is available on ARM just yet.HomebrewHomebrew currently works via Rosetta 2. Just prefix everything with arch -x86_64 and it’ll just work. It is possible to install an additional (arm-based) version of Homebrew under /opt/homebrew and mix setup, as more and more software is adding support for arm.This is not a problem currently (performance is good) and will eventually just work natively.ApplicationsMost applications just work, Rosetta is barely noticeable. Larger apps to take a longer initial performance hit (e.g. Microsoft Word takes around 20 seconds until everything is translated), but then these binaries are cached and subsequent runs are fast.There’s the occasional app that can’t be translated and fails on startup (e.g. Beamer or the Google Drive “Backup and Sync” client), but this is rare. Some apps are confused about their place on disk and ask to be moved to the Applications directory, when really it’s just the translated binary that runs somewhere else. Most of these dialogs can be ignored. Some apps (e.g. Visual Studio Code) block auto-updating as the translated app location is readonly. However, in case of VS Code, the Insider build is already updated to ARM and just works.Electron-based apps are slow if they run on Rosetta. It seems the highly optimized V8 JavaScript compiler blocks ahead-of-time translation. The latest stable version of Electron (Version 11) already fully supports Apple Silicon, and companies like Slack already updated their beta version to run natively.Google just shipped Chrome that runs on ARM, however there’s still quite a performance gap between it and Apple Safari, which just flies on Apple Silicon.ConclusionThe new M1 MacBooks are fast, beautiful and silent and the hype is absolutely justified. There’s still a lot to do on the software-front to catch up, and the bugs around older iOS Simulators are especially problematic.All of that can be fixed in software and the whole industry is currently working on making the experience better, so by next year, when Apple updates the 16-inch MacBook Pro and releases the next generation of their M chip line, it should be absolutely possible to use a M1 Mac as main dev machine.For the time being, the M1 will be my travel secondary laptop, and I’ll keep working on the 2,4 GHz 16-inch MacBook Pro with 32 GB RAM, which just is the faster machine. I’ll be much harder to accept the loud, always-on fans though, now that I know what soon will be possible.Let’s block ads! (Why?)</p>
