テスト1212件が全部通った版で、カレンダーと写真の保存が死んでいた — アプリの土台を3世代まとめて上げた記録 — 制作日誌 #31
制作日誌

テスト1212件が全部通った版で、カレンダーと写真の保存が死んでいた — アプリの土台を3世代まとめて上げた記録 — 制作日誌 #31

新しいウィジェットを出すために、アプリの土台を3世代ぶん上げた。型の検査は0件、テストは1212件すべて通り、審査も通って公開した。それでも、端末のカレンダーとの連携と、写真の保存が丸ごと動いていなかった。検査の網のどの段で何が見えて、何が見えなかったのかを段ごとに並べた。

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

家の土台を入れ替える工事に似ている。柱も壁もそのままで、基礎だけを新しい規格に替える。図面の検査は全部通る。住んでみて初めて、2階の水道が出ないと分かる。

自作のタスク管理アプリ「the task」で、9月下旬にこれをやった。土台にしている部品の集まり(Expo)を、版54から版57へ、3世代まとめて上げた。

なぜ3世代も飛ばしたのか

理由は1つで、iOS 27 の新しい大きなウィジェットを出したかったからだ。

必要なことそれを満たすもの
大きなウィジェットを組み立てられる新しい組み立て道具(Xcode 27)
その道具で組み立てた版が、起動直後に落ちない画面の管理の新方式に対応する設定。これは版57以降にしか無い

つまり、道具だけ新しくしても、土台が古いままでは起動した瞬間に落ちる。土台を上げるしかなかった。

検査の段ごとに、何が見えたか

土台を上げた後の作業を、検査の段で並べる。上の段ほど手元で速く回せて、下の段ほど実際の利用に近い。

段見つかったものこの段で見えなかったもの
① 導入導入の失敗を「成功」と返す道具—
② 型の検査名前や引数が変わった所 6種類呼ぶと失敗する中身
③ 自動テスト 1212件時間切れになる1件端末の機能につながる部分
④ 組み立て依存の導入で1本失敗画面の見え方
⑤ 審査・公開何も無し何も無し
⑥ 実際に使うカレンダー連携の全滅、写真の保存の失敗—

⑤までは全部通った。落ちていたのは⑥だけだった。以下、段ごとに中身を書く。

① 導入:「成功」と返すのに入っていない

部品をまとめて新しい版にそろえる公式のコマンドは、部品どうしの相性の衝突で導入が止まっても、成功の合図を返した。部品の一覧の紙だけが新しくなり、実際に入っている中身は古いまま、という状態が起きる。

そこで、導入の後に必ず「実際に入っている版」を1つずつ読み出して確かめる手順にした。紙ではなく棚の中身を見る、ということだ。

もう1つ、以前の版で自分が当てていた手直し(3本)を新しい版に当て直すとき、途中の残りかすを消し忘れると、手直しのファイルが 17KB から 66KB に膨らんだ。関係の無い差分まで抱き込むからだ。3本とも作り直した。

② 型の検査:変わった名前は全部見つかる

ここは検査がよく働いた段だ。

変わったこと直した量
画面いっぱいに広げる指定の名前が廃止21か所
端末の明暗の設定に「未指定」という値が増えた受け口を広げた
明暗を「端末に合わせる」に戻す書き方が変わった書き換え
カレンダー部品の型の名前が変わった名前で書かず、関数の戻り値から型を取る形に
タブのアイコンと文字の部品の置き場所が移動読み込み先を変更
テストの下準備の部品が別の包みに分離入れ替え

最後は型の検査のエラーが0件になった。

一番怖かったのは、画面の移動を担う部品が、中に別の部品の写しを取り込んでいたことだ。前と同じように外から同じ部品を読むと、見た目は同じでも別物になり、タブの帯の高さが合わずに黙って代わりの値に落ちる。落ちても何も言わない。読む先を写しの側に付け替えた。

③ 自動テスト:1212件

テストは 1212件すべて通った。1件だけ、全部を同時に流したときに5秒の制限に触れたが、単独で流すと2.1秒で終わる。不具合ではなく混み合いなので、制限を20秒に広げた。

ここで「中身は大丈夫」と思った。実際には、テストは端末のカレンダーや写真の保存先そのものには触らない。そこは偽物に差し替えて流している。差し替えた偽物は、新しい版でも正しく動く。

④ 組み立て:1本失敗、2本通過

組み立ての1本目は、依存の導入の段で落ちた。手元では相性の衝突を無視する設定で導入していたが、組み立ての機械は素の手順で導入するので衝突で止まる。設定ファイルに1行足して直した。

大きなウィジェット入りの版は、別の組み立てサービスで作った。その月の無料枠は 500分のところ524分使っていて、従量課金(1分あたり 0.095ドル)に切り替わっていた。1本の組み立てが12分、約1.1ドルだった。

⑤ 審査と公開

審査は通り、1.0.30 として9月24日に公開した。

⑥ 実際に使って、2つ死んでいた

カレンダー連携の全滅

公開した版で、端末のカレンダーへの書き出し、ほかのカレンダーの予定の表示、権限の確認が、すべて動いていなかった。

中を開くと、カレンダー部品の新しい版では、古い呼び方の関数が残っているものの、中身が「呼ぶと必ず失敗する」ものに差し替わっていた。警告を出して動く、ではなく、動かずに失敗する。

読み込み先を「古い呼び方用の入口」に変えるだけで直った。部品の本体は組み立て済みの版に入っていたので、組み立て直しではなく、中身だけの差し替え配信で済んだ。

5日後、写真の保存

9月29日、自分の端末で「写真の保存ボタンが押せないように見えて、押すと保存に失敗する」ことに気づいた。

原因はカレンダーと同じ形だった。写真の保存の部品も、古い呼び方の関数の中身が「必ず失敗する」になっていた。そして、失敗は受け止める処理に拾われ、画面には「保存できませんでした」と一言出るだけだった。

押せないように見えたのは別の理由で、暗い見た目のときにボタンの印が黒くなり、半透明の黒の上に乗って沈んでいた。印を白に固定した。

同じコードから出している3つのアプリ全部に、同じ直しを入れた。

網の穴はどこにあったか

2件とも、次の3つが重なっていた。

条件カレンダー写真の保存
古い呼び方が、名前はそのまま残っていたはいはい
型の上では、前と同じ形で呼べたはいはい
失敗を受け止めて、画面に小さく出すだけだったはいはい

名前が残っているので②を抜け、偽物に差し替えるので③を抜け、組み立ても審査も中身までは見ないので④⑤を抜けた。

例えるなら、コンセントの形はそのままなのに、裏の配線だけ外された状態だ。差し込めるし、図面にも載っている。電気だけが来ない。

直し方として、土台を上げたときの手順に1行足した。部品の中に「呼ぶと必ず失敗する」印が仕込まれていないか、文字で機械的に探す。探す言葉は決まっているので、1分もかからない。カレンダーのときにこれをやっていれば、5日後の写真の保存は、使っていて気づくより前に見つかっていた。

1212件のテストが全部通ったことは、嘘ではなかった。ただ、テストが見ていたのは、自分で書いた部分と、自分で用意した偽物だった。土台の部品が中身を入れ替えたかどうかは、最初から網の外にあった。

コメント (0)

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