M1/M2 Macbooks - Pains and Frustrations

We have the privilege of seeing up-close a wide range of development environments, and have seen certain pains repeat themselves over and over again. One of these revolves around the usage of ARM-based Macbooks (M1/M2) as development machines. While the new CPUs have been a game-changer for performance and energy efficiency, they’ve presented unique challenges for developers. In this blog post, we'll explore the biggest challenges developers face when working with ARM Macbooks for development.

## Compatibility issues

The biggest challenge of working with ARM Macbooks is compatibility issues. Because they run on a different processor architecture, some software may not be compatible. Some things can be overcome using Rosetta, Apple’s built-in x86 emulation, but others cannot, and fail to compile or install.

Things that do work with Rosetta run significantly slower than they would have on x86-based computers, leading to frustration as precious time is spent waiting for software to come up, when switching apps, or when performing cpu-intensive tasks such as compiling or building images.

## Virtualizing other operating systems

Another area of pain is centered on virtualization. On the one hand, some virtualization software is not yet optimized to work on ARM Macbooks, leading to suboptimal performance. On the other, the target operating system may not have an ARM version, leading to very slow performance due to emulation. This means that quickly spinning up virtual machines isn’t an option anymore, and if that is an integral part of the workflow, for testing the software’s behavior under different operating systems, it is something companies should take into account.

## Difficulty in finding support and resources

Finally, finding support and resources for ARM Macbooks can be a challenge. As this is a relatively new configuration, it is still common to encounter problems that are related to the architecture. When searching the internet for solutions, most of those found are unrelated to the CPU architecture, leading to troubleshooting iterations that do not solve. This delays development and creates frustration for the entire team.

## Underlying cause

The underlying cause of all of this pain during development is that the runtime in which we are developing is dissimilar to the environment in production. If they were identical, we would have been able to run anything that runs in production during development with the exact same configuration. In most companies, production is based on linux VMs running on x86 CPUs. This is a super common platform for production, staging and all other environments.

At Raftt we’ve seen companies try to resolve these problems with various means, but with little success. The only solution that can fully eliminate this problem is to consolidate all the environment’s runtime to the same CPU and operating system. Companies often worry about how this will impact their developers' convenience and effectiveness. But with Raftt - their dev speed is accelerated.

## Raftt to the rescue

Raftt gives developers the best of both worlds - the convenience, flexibility and speed of their local IDE and tools, with a runtime that matches their company’s production stack. Everything in the environment - micro services, supporting software and databases, and both in production configuration and during debugging - is run in a remote Kubernetes cluster with the same runtime as production. So you get fast iterations and full development capabilities and entirely eliminate CPU architecture compatibility troubles.

Raftt can orchestrate your development environments, or connect to existing environments hosted on Kubernetes, no matter what tool creates them. To hear more, [contact us](https://www.raftt.io/contact).

‍