Se você trabalhar comigo em algum momento, deve ouvir minha recomendação de usar algum gerenciador de versão Ruby, como rbenv . Mesmo no que diz respeito a escrever um guia Notion para o novo guia de integração do engenheiro na empresa com a qual estou trabalhando atualmente, usando o rbenv como um requisito. Mas por que se preocupar em usá-los?

Este artigo é mais como um porquê e um monte de parágrafos que contêm histórias e motivos. Portanto, você não deve pular e ler do início ao fim, em vez de procurar uma parte TL;DR.

Afinal, para que usamos Ruby como desenvolvedor iOS?

Muitas coisas! Bem, mais ou menos. Existem muitas ferramentas que são usadas como ferramentas complementares ou utilitárias que são escritas em Ruby, especialmente as ferramentas maduras dos últimos anos. Por exemplo, Cocoapods e seus plugins. Em alguns momentos antes da Apple decidir criar o SPM, é seguro dizer que quase todos nós usamos o Cocoapods como nossa principal ferramenta para gerenciar dependências de terceiros . Outras ferramentas que são muito comuns de usar e que gostaria de mencionar são o Xcodegen e o Fastlane. Sim, esses dois também são escritos em Ruby. Tantas ferramentas e scripts utilitários são escritos em Ruby. O idioma está lá como parte do seu dia-a-dia, quer você goste ou não.

Já não temos Ruby embutido em nosso MacOS? Por que temos que usar outro

Sim nós fazemos. Os MacOS-es têm seu próprio Ruby instalado na raiz do sistema e, sim, ele funciona como o Ruby normal e funcionará na maioria das vezes. A palavra-chave aqui é na maioria das vezes. Normalmente, a maioria das pessoas não tem nenhum problema em relação a ferramentas baseadas em Ruby que foram mencionadas anteriormente em seu trabalho diário. Mas até um pequeno soluço que começou alguns anos atrás. A nova era do silício da Apple.

Apple Silicon, arm64 e gemas Ruby desatualizadas.

Devido à diferença no tipo de arquitetura usada pelo Macbook mais recente, a arquitetura baseada em Apple Silicon arm64, muitas gems Ruby desatualizadas precisavam ser suportadas nativamente. Muitas pessoas que são novas nesse tipo de problema estão pesquisando no StackOverflow e seguindo a solução de usar Rosseta2 ou adicionar o parâmetro -arch x86_64 à execução do terminal. O que… eu não gosto!

Quanto mais sua base de código depender de ferramentas baseadas em ferramentas de gemas Ruby, maior a probabilidade de você ter esse problema.

Mas e se eu dissesse que essas gems Ruby nem sempre estão desatualizadas e sem manutenção? A maioria dessas gems quebradas lançou seu suporte atualizado para a arquitetura arm64. Eles podem ser executados nativamente no Apple Silicon! Não é necessário mais Rosseta!

A única coisa que essas gems normalmente precisam é rodar na versão mais recente do Ruby 3.xx ao invés da versão 2.6.x integrada.

Em vez de confiar no Rosetta como uma solução irregular, prefiro executar minhas ferramentas em um 3.x. x instância Ruby.

Então, por que não atualizamos o Ruby do nosso MacOS?

Já sabemos que a instância Ruby integrada é colocada em nossas raízes do sistema , localizadas em /usr/bin/ruby, que é o usuário root, também conhecido como superusuário do sistema.

É por isso que toda vez que você tentar instalar uma nova gem globalmente, você deve usar o sudo em seus comandos. Indiscutivelmente, essa prática pode levar a um problema de segurança indesejado se você não prestar atenção.

Com essa abordagem, nunca preciso usar o sudo sempre que quiser instalar gemas Ruby adicionais.

A Apple também tem motivos para não enviar a instância mais recente do Ruby para o macOS que não conhecemos. Quero garantir que a estabilidade do macOS seja mantida, por isso é melhor fazermos algo fora da instância do ruby ​​raiz do sistema e fazermos todas as nossas necessidades, como atualizar e instalar gemas Ruby adicionais nesse local.

Mude as versões do Ruby sempre que precisar (adicional)

O ponto anterior já menciona que você economiza uma dor de cabeça ao lidar com suas joias que não funcionam para serem usadas com uma máquina Apple Silicon sem emulação de roseta. Para a maioria das pessoas, basta convencê-las a usar um gerenciador de versão Ruby. Mas, no meu caso, já que eu cuido do fluxo de trabalho de CI/CD do iOS e 'ajudo' outros engenheiros a lidar com esse tipo de coisa (solução de problemas de ferramentas). Frequentemente preciso de flexibilidade em meus ambientes Ruby. Por exemplo, o Xcode CI Server ainda está usando uma versão 2.6.x (e no meu caso, está funcionando bem, pois ainda é uma máquina Intel), às vezes tenho que mudar para versões semelhantes em minha máquina para simplificar sobre como configurar o pacote Gemlock.file. Ou às vezes, Preciso instalar uma nova instância do Ruby para emular e testar se um novo membro com uma máquina limpa pode seguir nosso guia de integração. Ter um gerenciador de versão Ruby pode ajudar com esse tipo de coisa.

Etapas para usar e instalar o rbenv

Vou usar o rbenv como o gerenciador de versão ruby ​​de minha escolha. Você pode usar qualquer outro tipo de gerenciador de versão ruby ​​para obter os benefícios mencionados anteriormente.

1. Instale o Homebrew copiando e colando-o no seu terminal.

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew install rbenv ruby-build

rbenv install 3.1.1
rbenv global 3.1.1

Conclusão

Suponha que você tenha algum problema ou não consiga fazer algumas de suas gemas/ferramentas de rubi em seu desenvolvimento iOS diariamente por causa da máquina de silício da Apple e seja forçado a usar Rosetta em seu terminal. Nesse caso, você pode tentar acompanhar este artigo, ficar longe do Ruby embutido nas raízes do sistema do seu macOS e aproveitar para ficar longe do sudo completamente.

Felicidades!