Apple Silicon（M1 chip）を搭載したMac（以下 M1 Mac）に、iOS・Androidのアプリ開発環境を整備した際に遭遇したトラップをまとめます。
便利なコマンド
-
uname -m- 実行中のシェルが、どのアーキテクチャで実行されているかを確認できる
-
arch -x86_64 実行したいコマンド- x86_64アーキテクチャでコマンドを実行する（
arch -arch x86_64 実行したいコマンドと同じ）
- x86_64アーキテクチャでコマンドを実行する（
-
arch -arm64 実行したいコマンド- arm64でコマンドを実行する（
arm64eでも同じっぽい？）
- arm64でコマンドを実行する（
iOS・Android共通
Homebrewを使うなら、インストール先は /opt/homebrew のままにしておく
M1 MacにHomebrewをインストールすると、brew installを実行した時の保存先は /opt/homebrew/bin/* になる。
なお、Rosetta 2を使用してシェルを実行している場合は、/opt/homebrew・/usr/localどちらにインストールするかを選択するプロンプトがあったはずだが、ここはデフォルト設定にしておく。
iOS
rbenv等は使わない、システムのRubyを使う
-
rbenvを使うと、CocoaPodsを動作させることができない- システムのRubyを使用する
- CocoaPodsが依存する
ffiがarm64に対応していないことが原因 - M1 macでpod installができない。sudo gem install ffiをしても治らない(rbenvが原因)
じきに対応するとは思うが……。
CocoaPodsが動かない場合
- CocoaPodsが依存する
ffiのバージョンが古い可能性がある- ターミナルアプリ（iTerm2なども）を、Rosetta 2で開くように設定する
-
bundle update ffiまたはgem update ffiを実行する - M1 Macでpod installを実行する
完全なApple Silicon環境は、まだ遠いようだ…。
CocoaPodsで導入したライブラリが原因でシミュレータ向けビルドができない場合
これはM1 Macというよりは、Xcode 12なのかもしれないけど……。
いわゆる以下のエラーの問題。
building for iOS Simulator, but linking in object file built for iOS, for architecture arm64
Intelのときは発生しなかったのに、M1にしたら発生し始めるプロジェクトにも遭遇した。以下のリンクなどをよく参考にさせてもらって、どうにか対応した。
プロジェクトによっては、アプリのターゲット、もしくは、プロジェクト自体の方でも「Excluded Architectures」の設定をしないとビルドできないこともあった。
MintはMINT_PATHとMINT_LINK_PATHの変数を指定して実行する
mint実行前に MINT_PATH と MINT_LINK_PATH をセットしておく。このパスは、アクセス権限のあるディレクトリでなければならない。
上記変数を指定しない場合、mintでインストールするパッケージは、デフォルトの /usr/local/lib/mint にインストールしようとする。しかしBig Surでは（M1 Macでは？）、このディレクトリのオーナーがrootに変わっているため、インストールすることができなくなっている。
https://github.com/MakeAWishFoundation/SwiftyMocky/issues/279
https://github.com/yonaskolb/Mint/issues/188
対策として、上のリンクにあるように /usr/local/lib/mint のオーナーを変更する方法もあるが、あまり安全とは言えない。そのため、 MINT_PATHやMINT_LINK_PATHは、自身の管理できるディレクトリ（例えばプロジェクトのディレクトリ等）に置くのが良さそうだ。
$ MINT_PATH=${PROJECT_ROOT}/mint/lib MINT_LINK_PATH=${PROJECT_ROOT}/mint/bin `which mint` bootstrap --link
Carthageは特に問題なく動いた
Carthageもなにかトラップがあるだろうと構えていたが、思いの外、問題なく通過できた。
Fastlaneも特に問題なく動いた
今のところ大丈夫そう。
Node.jsも問題なく動いた（条件付き）
僕が試したところだと、２つの問題がありそうだった。arm64への対応状況と、npmの挙動について。
なお今回は、anyenv経由でnodenvをインストールして動作を確認した。
arm64への対応状況
最新版は対応できているようだが、バージョンによってはarm64に未対応。
ただし、ネイティブアプリ開発の場合は、依然としてRosetta 2を使うため、arm64への対応状況自体は大きな問題にはならなそうだ。
npmの挙動
グローバルにインストールしたパッケージは動作問題なし。パスも通っていたし、直接コマンドを呼び出して実行することができた。
一方、ローカルにインストールしたものは、うまくパスが通らなかった。
npm binをした際にパスは出るものの、コマンドをnpm execで呼ぶ必要があり、直接呼び出すことができなかった。
（anyenvやnodenvの設定の問題かもしれない……）
Android
インストール時、Intel向けのツールはインストールに失敗する
標準インストールでなく、カスタムインストールを選ぶなら、
EmulatorやIntel HAXMのチェックを外すだけで良さそう。
エミュレータはプレビュー版を使う
arm-v8a用のイメージがプレビューで公開されている。AVD Managerでエミュレータを新規で作成するときに、arm64-v8a用のイメージを選択できるようになっている。
一方で、このウィザードでダウンロードするイメージには、不具合があるRevisionだったりするので注意したい。
例えば、エミュレータを起動していてもオフラインとして検出され、Android Studioからアプリを転送できなかったりする。
もしこのような現象に遭遇したら、いくつかの情報をあたって「動作する」と言われているRevisionのイメージを、手作業でインストールする方が、懸命なことがある。
具体的な方法については、以下のサイトを参考にして行う。
イメージをダウンロードするサイトは、こちら。
2021/07/19現在、ARM64-v8a向けには、Rev. 9のイメージがある。このRevisionでは、エミュレータがオフラインにならずにアプリをデバッグすることができた。
M1 Macは、iOS開発でトラップが多い
Androidは比較的スムーズに環境構築ができたが、iOSについては、トラップがめちゃくちゃ多かった……。特に、Ruby周りとCocoaPods周りにトラップが多い。
とはいえ、M1 Macがリリースされてから半年以上になるので、このあたりのトラップに対する解決策はネット上にたくさんある。おかげで安心してM1に移行していけそうだ。
そういえば、これを読んでいる人の中には、OSSだけでなく外部ベンダーが開発したクローズドなライブラリを使っている人もいるだろう。そういったライブラリが引き金になってビルドできない場合もあるようなので、早めにM1 Macで検証しておくのが良いだろう……。