検査は全部通ったのに、焼いたら2回落ちた — Xcode 27 で初めてビルドした日の関所 — 制作日誌 #26
制作日誌

検査は全部通ったのに、焼いたら2回落ちた — Xcode 27 で初めてビルドした日の関所 — 制作日誌 #26

iOS 27 の新しい大きなウィジェットを出すために、初めて Xcode 27 でアプリを組み立てた。手元の検査はすべて通っていたのに、1本目と2本目は別々の理由で落ちた。3本目で通ったと思えば、今度は起動直後に落ちた。机の上では見えない関所を、1つずつ記録しておく。

KIYODO
#個人開発#アプリ開発#iOS#失敗談#制作日誌

作っているタスク管理アプリに、iOS 27 で増えた「特大」サイズのウィジェットを載せたかった。ホーム画面に縦長で置ける、いちばん大きな枠だ。

ただし、この枠を作れるのは Xcode 27(Apple の開発道具の最新版)だけだった。普段アプリを組み立ててもらっている外部のサービスは、まだ1つ前の Xcode 26 までしか用意していない。そこで、Xcode 27 の機械を先に用意していた別の組み立てサービス(Codemagic)に初めて頼むことにした。

私の手元には Mac が無い。Windows で書いて、組み立ては全部よそに任せている。つまり「本当に組み上がるか」は、実際に投げてみるまで分からない。

それでも自信はあった。型の検査も、単体のテストも、設定の読み込み確認も、全部通っていたからだ。

結果から書くと、こうなった。

落ちた場所分かるまで原因の種類
1本目部品を組み込む段取り5分前後手順の順番
2本目仕上げの組み立て開始直後5分前後借りた部品の古さ
3本目通った(19分46秒)
その版起動した瞬間実機に入れてから新しい iOS の必須条件

4つとも、手元の検査では1つも引っかからなかった。1つずつ見ていく。

関所1:書いた順番どおりには動かない

1本目のエラーはこうだった。「ウィジェットの部品が見つかりません(見つかったのは本体だけ)」。

最初は名前の書き間違いを疑った。しかし名前は合っている。原因は順番だった。

アプリを組み立てる前には、設定を書き換える小さな処理がいくつも走る。私はその1つに「ウィジェットの部品に、特大用の設定を足す」処理を書いていた。ところが、そのウィジェットの部品そのものを作るのは、別の処理の担当だった。

この書き換え処理には、あらかじめ走る順番が決まっている。道具の中を読むと、優先度が -2、-1、0、1 の4段に分かれていた。私の処理は「-1」の段、部品を作る処理は「0」の段。つまり、部品が生まれる前に、その部品を探しに行っていた

料理で例えるなら、盛り付け係が鍋より先に厨房へ入ってしまった状態に近い。

例え実物
盛り付け係特大用の設定を足す処理(-1の段)
鍋で料理を作る係ウィジェットの部品を作る処理(0の段)
「料理がありません」部品が見つからないというエラー

厄介なのは、設定ファイルで処理を並べる順番を入れ替えても何も変わらないことだ。並べた順と走る順は別物になっている。直し方は、自分の処理を最後の段(1の段)へ移すことだった。ここなら、他の処理が全部終わった後に走る。

関所2:借りてきた部品が古すぎた(エラー10件)

1本目を直して投げ直すと、今度は仕上げの組み立てが始まった直後に止まった。エラーは 10件 まとめて出た。

中身はどれも同じ種類だった。「この部品は iOS 15.0 より古い端末向けに作られているので扱えない」。

アプリは、自分で書いたコードだけでできているわけではない。広告を出す部品、画像を読む部品、課金を扱う部品、保存を扱う部品。外から借りてきた部品が何十個も入っている。そのうちのいくつかが「iOS 9.0 から動きます」「12.0 から動きます」といった古い設定のままだった。

Xcode 26 までは、これは注意で済んでいた。Xcode 27 から、同じものがエラーに格上げされた。昨日まで黙って通っていたものが、道具を新しくした途端に通れなくなる。

ここでもう1つ落とし穴があった。私はすでに「アプリの最低対応を上げる」処理を持っていた。ところがそれは、自分のアプリ側の設定にしか効かない。借りた部品の設定は、組み立ての最後のほうで部品の管理役(CocoaPods)が別に作る。私の処理が走る時点では、まだ存在すらしていない。

直し方は、部品の管理役が設定を作り終えた直後に割り込み、すべての部品の最低対応を iOS 17.0 に揃えさせることだった。割り込む場所が見つからなければ、黙って進まずに組み立て自体を止める作りにした。

同じ部品を使っている姉妹アプリ2つにも、同じ直しをその日のうちに入れた。

通ったと思った3本目

3本目は通った。所要 19分46秒、出来上がったアプリの大きさは 42.2MB。中を開くと、特大ウィジェットが 5種類 ちゃんと入っていた。

テスト配布に回して、実機で開いた。その瞬間に落ちた。

原因は特大ウィジェットではなかった。iOS 27 の道具で組み立てたアプリは、「画面の出し方」を新しい作法に対応させていないと、起動した時点で止められるようになっていた。今のアプリの土台(Expo の版)には、その作法に対応するための設定がまだ無かった。

ここで特大はいったん諦めた。前の Xcode で普通の版を組み立て直し、起動することを確かめてから、土台そのものを新しい版へ上げる作業に入った。

土台を上げた後の1本

土台を上げた後、Codemagic でもう一度組み立てた。この回も1本目は落ちた。今度は特大ウィジェットの画面を描くコードの書き方で、古い Xcode では読み飛ばされていた部分だった。これも組み立てるまで見えない。

直して投げた次の1本で、ようやく特大入りの版がテスト配布まで届いた。組み立ては 12分

お金の話も残しておく。Codemagic には月 500分 の無料枠があるが、9月はこの時点ですでに 524分 を使い、枠を超えていた。超えた分は1分 US$0.095 の従量課金で、最後の1本は 約US$1.1 だった。手元に Mac があれば払わずに済んだ額だが、Mac を買う額と比べれば小さい。

検査の内側と外側

振り返ると、落ちた4回はどれも同じ場所にあった。「自分のコードが正しいか」の外側だ。

  • 段取りの順番(誰が先に走るか)
  • 外から借りた部品の状態(古い設定のまま)
  • 新しい iOS が課す条件(起動の作法)
  • 古い道具では読み飛ばされていたコード

型の検査やテストは、書いたコードの中身を確かめるものだ。組み立ての段取りや、借り物の部品の中身までは見に行かない。だから「検査が全部通った」は、この4つについては何も保証していなかった。

1つだけ救いがあったのは、関所1と関所2がどちらも開始から5分前後で落ちたことだ。最後まで走ってから落ちていたら、1回ごとに20分近くを失っていた。道具の版を上げて初めて組み立てる回は、最初の数分で落ちる前提で張り付いて見ている。今回はそれで、無駄を最小限にできた。

特大ウィジェットは、まだ実機のホーム画面に置いて確かめていない。テスト配布に届いたことと、実際に動くことは別の話だ。それを確かめるまでが、この作業の残りになる。

コメント (0)

まだコメントはありません。最初の一言を残しませんか?