Xcode 12.5 では直ってなかったが Xcode 13 Beta で直ったようだ。めでたい。
Apple にバグレポート送った。
Intel Mac だと再現しない。M1 Mac のみ。
たぶん Xcode 側に問題があるので、待ってりゃ直るんじゃないかな。
@IBDesignable
関連について Apple 的には失敗作だったと思ってそうな節があるような気がしている…(個人の感想です) 手元でちょっとプレビューさせるくらいなら力技で一応なんとかできる。
世間的な流れはもう SwiftUI なんだろうけど、実際のところ全てを SwiftUI で実装していけるかというと別にそんなことはない。ややこしいインタラクションを実装したりするなら UIView
をベースに作るのは今でも良い選択だと思う。
とは言え、個人的にはコードでの UIView
関連の実装を避けられるなら出来るだけ避けたい。そういう訳で、自分が面倒を見ている範囲では @IBDesignable
と @IBInspectable
を多用している。
@IBDesignable
を便利に使うテクニックとして、 TARGET
を分けて別の framework にしておく手法がよく知られている。こうすることによって、 InterfaceBuilder を開いたときに走るビルドを最小限に抑えられるというメリットがある。
要するにこういう図の感じに設定して、この例だと DesignableComponents
っていう Framework を切っているのだが、その Framework の中でカスタムの DesignableView
みたいなのを実装しつつ、アプリケーション側の TARGET にある Storyboard とか xib でそれを使う、というイメージ。
その中で @IBDesignable
周りと InterfaceBuilder 周りはあまりメンテされてなさそうな感じというか、そういうやる気がなさそうというか、メンテが難しそうな構造になってるのかなというか、各所に微妙なハードコーディングされた実装がありそうだなというか、そういう雰囲気を感じさせるエラーが発生しているという、つらい話です。
https://github.com/dnpp73/BrokenFrameworkDesignable
問題が起こるのは M1 搭載機種のみ。これを Xcode 12.4 で開いて Main.storyboard を見ると
こんなエラーが出る。
エラーメッセージが言ってることは大体同じで、要するに DerivedData
内にあるべき framework が見付からんぞ、見付かったとしても iOS Simulator 向けのビルドじゃないから使えんぞ、といった感じである。
見出しの通りなんだけど、どうやら
${Configuration}-iphoneos
ディレクトリ内を探しにいく。${Configuration}-iphonesimulator
ディレクトリ内を探しにいく。という感じのようだ。この場合 Intel Mac 側の挙動が正しい。恐らく Xcode の実装のどこかにアーキテクチャ依存の分岐か何かがハードコーディングされてるんじゃないか…と思わせる挙動である。
ちなみに DerivedData
内の [...]/Build/Products
内に
${Configuration}
→ Mac 向けの成果物${Configuration}-iphoneos
→ iPhone 実機向けの成果物${Configuration}-iphonesimulator
→ iOS Simulator 向けの成果物が入ることには変わりないし、ここは間違ってない。
困ったことに M1 Mac だと ${Configuration}-iphoneos
を探しに行ってしまい、そこには普通にしていると Simulator 向けのビルドが入ることがない (実機向けのビルドが入ることはある) ため、エラーメッセージがちょいちょい変わりながら出続けてユーザーを翻弄してくることになる。つらい。
そして実際の開発現場ではもっと複雑な xcodeproj を運用しているだろう。入り組んだ Framework Target やら、そこに Carthage や Swift Package Manager やらで依存ライブラリを入れたりなんだりしてるはずで、ビルド時のエラーメッセージがちょいちょい分かり辛い感じになる。実際はもっとつらい。
とりあえず探しに行った先に必要なファイルが存在さえすれば @IBDesignable
のプレビューだけは通るようになる。
この場合は
DerivedData
内に生成された ${Configuration}-iphonesimulator
を ${Configuration}-iphoneos
に cp -r
するEditor
→ Refresh All Views
するか Xcode を再起動する。という泥臭いことをすれば、一応通る。
しかしこんな野蛮なことをするのは全くよくない。
本来実機向けビルド成果物が入るところにシミュレータ向けのビルド成果物を入れてる訳なので、このまま DerivedData
を掃除せずに実機で実行させようとすると死ぬと思われる。
ちゃんと対応するのは結構めんどい感じがしている。
というか Apple が見限ろうとしているものにしがみ付くのは良くないことは経験的に分かっていて何とも言えない。SwiftUI へ移行せよということか。まだちょっと色々不便なんだけどな…。
ちゃんとやるなら Xcode にバグレポートを送るべきだろうし (追記: 送りました) 、直るまでの間はワークアラウンドなシェルスクリプトを書いて、適当な位置に Run Script
フェーズを挟んでそこ実行するみたいなことをやることになるか、そんな気がしている。
ググってる最中で 同じ問題に直面して困っている人を Stack Overflow でも見付けた のだが、ここに付いてるレスでは解決できないように思われる。世知辛いですね。(追記: 一応解決方法あるけど微妙だよねみたいなコメント書いときました)
M1 の MacBook Air をメインの開発機にしてから数週間経った。
細かい問題は度々発生するものの、都度ググれば大体先人が何かしら工夫して解決している情報に辿り着けるし、そうでなくてもまぁ大体こんなもんだろって感じで解決策にアタリを付けて回避はいくらでもできるし、その辺はあまりデメリットにならないと感じている。
iOS アプリ開発の現場では…問題は結構起こるけど、まぁなんとかなる。
体感としては大体アーキテクチャ依存の問題を引いてくる感じ。
というか Web フロントエンド開発や Rails 周りの開発を、ローカル環境だったり手元の Docker 環境に作ってなんやかんや仕事する方が問題が起こらないまである。
色々差し引いてもワットパフォーマンスが異常に良くてバッテリが死ぬほど持つし、全然熱くならないし、普通に速いし、キーボードは打ちやすい…。
Touch Bar 搭載のモバイル向け Intel プロセッサ搭載 MacBook Pro は全体的に悪夢だったと言える。あれは一体なんだったんだ。