Yes, Try Out the M1 Macs, But Don't Commit Your Engineering Team to it Yet

I ordered the new @Apple #M1 #macmini on the new online Apple store in India. (Finally, they made the online store available in India! It only took a pandemic.) While, I'm looking forward to my new machine, I'm not yet sure that it makes sense to start ordering #M1 Macs for your developers. Many critical things are still missing. And whether or not your development team can live with the compromises is a function of their development workflow.

iOS, watchOS and macOS Development

If your objective is to enable your developers to improve their #iOS app development workflow, then don't hesitate. The #M1 Macs are just right investment for your engineering org. #Xcode runs flawlessly on #macOS and emulation isn't even needed to test your apps. So your developers' cycle time should be much better given the blazingly fast processor and graphics, and attractive per FLOP prices.

For other types of development environments, the answer is not so clear cut. You may want to have one of your lead developers try out the environment for a few months before upgrading your IT infrastructure.

C/C++ Development

The native Clang compiler has the same interface and works perfectly for #C and #C++ code. But, for any reasonably sized project, you will find that most libraries even if they recompile on the new M1 macs reasonably fast, will encounter difficulties with the architecture. Your mileage here will critically depend on which third-party libraries you need to use.

In particular, performance will very likely be sub-optimal if the apps are not using macOS BigSur's APIs.

XQuartz still requires Rosetta2 and the X11 libraries need to ported, or at least recompiled.

Many scientific computing libraries are available for ARM and will work reasonably well. But some machine learning libraries will work better if they take advantage of the neural engine. So use of the macOS BigSur API is critical.

This is just the tip of the iceberg with C++ development. Many other problems may abound. The more esoteric your development toolchain, the more likely you will find it difficult to incorporate the #M1 mac into your workflow.

Virtualization

Docker doesn't currently work. Most current virtualisation tools will not work: VirtualBox for example.

Java Development

For #Java development, there is an #Azul Zulu JDK port available, but #Eclipse seems to have spotty record running. #Jetbrains #IntelliJ #IDEA seems to work, but it seems to be using the x86_64 version of the Java runtime internally, and will suffer from #Rosetta2 translation overhead. (Although perhaps not very noticeably.) If you've installed Azul though, the code you build will use the native JDK.

Android Development

Most of the caveats that apply to #IntelliJIDEA apply to #AndroidStudio and other #Jetbrains IDEs as well.

Although in theory, emulating devices like the #Pixel4 should be simpler with ARM based #M1 #Macs, it is not yet available. However, it looks like AndroidStudio will support device emulation on #M1 natively relatively soon.

NodeJS Development

For #NodeJS, somewhat surprisingly, given that #V8 is optimized for #ARM, the situation is a little worse. The core #Node runtime itself is not yet available for #M1. There are bug reports of the compile of source code working, but some tests failing. I expect this will be resolved fairly soon. #Electron does work natively for M1, but it's not clear that #VisualStudioCode is currently using the native Electron port.

Python, Data Science and ML

For #Python, Apple supplies a native #Python interpreter (I think #Python3,) but for most realistic development scenarios, many pip package installations will fail because of compile problems. The most practical way to use python on M1, for now, is to use x86_64 emulation via Rosetta2.

If you use #NumPy, #Pandas, etc. for Data Science or Machine learning, you may find that all of your code is running as emulated X86_64 code via Rosetta2. This may or may not be a problem depending on the size of the data set you are working on.

Although #TensorFlow is available for #ARM, it is not clear that TensorFlow actually uses the M1's neural engine and GPU cores. There seems to be a ticket open for TensorFlow to be ported to use those components on the Mac.

PHP, Ruby and Other Web Development Workflows

Most of the core platforms for both PHP and Ruby will run with Rosetta2 emulation, but your mileage will vary with the specific libraries and frameworks you want to use.

Linux and Open Source Tools

Most developers use either #Homebrew or #MacPorts for many open source tools. Currently, it seems they themselves require Rosetta2, and will very likely build x86_64 binary that will need Rossetta2. It is unclear that this will give good performance, particularly for slow interpreters like Python.

I'm really excited by the potential performance of the new #M1 Macs, but it may take a year or so for the toolchains for your preferred development environment to mature on the new platform.

If you are an engineering leader, who needs to take a call on whether to invest in the new M1 macs for your engineering, my advice would be to trial it with a few of your top engineers, and then make decision on switching based on their experience. In a large organization, each individual department may need to take a call separately.

We at Svertual help development teams optimize their development workflows for greater efficiency. If you need help on improving your teams development velocity, or managing your cloud deployments we can help. Contact Sumanth Vepa<[email protected]> for more information.