How to install unsupported development software on M1 Mac

Developers worldwide use Intel-based Mac computers every day, but many of them face issues setting up their development environment on Apple silicon M1 Macs.

The big transition from Intel to M1

In November 2020, Apple released the first Mac with an ARM-based M1 chip, along with the new MacBook Pro, MacBook Air and Mac mini models. From the release, the M1 chip received astounding reviews and praise for its efficiency and performance – and it marks Apple's transition from Intel chips that have been used for the last 15 years.

Suppose you consider buying a new Apple silicon supercharged Mac or MacBook Pro for development, but you are worried about transitioning your existing project from your Intel-based Mac. In that case, this blog will explain some development setup tips & tricks that will help you continue programming and make your transition easier.

Is the Apple silicon M1 suitable for developers?

Ever since Apple introduced the first M1 Macs two years ago, they delivered groundbreaking performance and amazing battery life.

In the beginning, M1 chips were only to be found on consumer-focused Macs and definitely came with some limitations – such as being able to support only one external monitor. The next step came a couple of months ago - in October 2021, when Apple introduced the new M1 Pro and M1 Max – new breakthrough chips for the Mac.

The first things we noticed are more powerful M1 architecture, more CPU cores, more GPU cores, more RAM, more ports on the MacBook Pro models – and the possibility of connecting more than one external display.

There are a lot of pros when it comes to new Apple M1 chips; however – there are some disadvantages that need to be addressed, such as software and tools you are used to may not be fully supported.

Although there is already a lot of software optimised for Apple Silicon, there are some that require an extra step in the form of a translation environment – such as Apple Rosseta, which translates apps designed for Intel architecture to M1 architecture.

The Software problem

Here in our company Devōt, we use both Intel-based, and M1 based Mac machines, and many of us are using the Homebrew package manager, which simplifies the installation of different software - like Ruby, Git, MySQL etc.

However, when trying to install some older versions of that software on the M1 architecture, we would soon run into many issues related to installing native extensions and different dependencies.

In order to resolve those issues and try to install failing dependencies, we tried many different solutions and extensions, which included different installations through the terminal on Apple and Intel architecture. The result was a huge development software mess that didn't look promising. For example, trying to install the older Ruby 2.3.6 version (which is not supported on M1 architecture), was constantly causing issues with ffi 1.9.18 gem and OpenSSL 1.0, (also not supported on M1 architecture).

After many tries with custom dependencies installations, Ruby 2.3.6. seemed to be installed. However, there were also Ruby bundler issues with installing project gems – all in all, a big mess.

One of the biggest problems in this transition is that some large–scale projects use an older technology stack, which may not be supported by M1 architecture. For example, Let's take MySQL Database Service - MySQL@5.6 is not supported on M1 architecture, and trying to install it with Home-brew on M1 architecture results in many different errors.

If by any chance, you somehow manage to install MySQL@5.6 with some custom installation commands, other software such as Bundler for Ruby probably won’t work – because MySQL@5.6 is not supported on M1, and again you can expect different errors.

So, what is the solution?

The solution is actually more straightforward than it may seem – you should use only one architecture for installing the entire technology stack in your development environment.

For example – with Rosseta, we can have 2 Homebrew systems installed – with Apple silicon architecture – Homebrew's default directory is /opt/homebrew. When installed with Intel architecture, there is a different default directory, and it is /usr/local.

When using the terminal, we can run commands in Rosetta (on the intel architecture), but mistakes can still happen, and we can end up with a mess again.

Example brew aliases:

alias rbrew="arch -x86_64 brew"
alias ibrew='arch --x86_64 /usr/local/Homebrew/bin/brew'

In our example, we use iterm on Mac as the main terminal app, and zsh shell with Oh My Zsh framework for Zsh.

Adding some aliases to zsh configuration file (.zshrc) to switch between Intel and Mac architecture can help us a lot in the environment setup – while installing all the libraries over homebrew and other tools and software.

alias armzsh="arch -arm64 zsh"
alias intelzsh="arch -x86_64 zsh"

To display in which architecture we are currently, we can add this setting to our zsh configuration file (.zshrc).

if [ "$(uname -p)" = "i386" ]; then
  echo "Running in intel arch (Rosetta)"
  eval "$(/usr/local/homebrew/bin/brew shellenv)"
  alias brew='/usr/local/homebrew/bin/brew'
else
  echo "Running in ARM arch"
  eval "$(/opt/homebrew/bin/brew shellenv)"
  alias brew='/opt/homebrew/bin/brew'
fi

Even though it may sound trivial, making sure you are in the correct architecture is crucial to avoid many issues caused by different homebrews.

For version manager, our suggestion would be asdf. asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis.

How does it work?

Most tools and programs will work perfectly fine on M1 architecture, but some tools require installation that won't work. In our example, running asdf install ruby 2.3.6 will fail due to architecture issues on M1, but if we switch to Rosetta using our alias command and run asdf install ruby 2.3.6, it will succeed. So now Ruby 2.3.6 is compiled and installed from Rosetta, and we can actually use it even on M1 architecture (armzsh).

As M1 Mac has only M1 architecture chip, you will have to adapt to M1 architecture if you plan to use it. How does it work on Apple M1 ARM architecture? Every time we use Rosetta to install an unsupported program or tool, Rosetta compiles it in Intel architecture – and then makes an M1 ARM installation. Rosetta is only required for compile and installs phase, and then our programs should work anywhere.

Since we use both Intel-based and M1 based Mac machines, feel free to check our other blogposts here https://devot.team/blog/how-to-install-unsupported-development-software-on-m1-mac, and contact us with any questions related to the development setup – we will gladly try to help.