自社で作っている一人社長向けの経理アプリで、TestFlight 用の Release アーカイブが50分経っても終わらなくなりました。原因は、コード生成で Swift に埋め込んだ大きな表でした。入れ子の辞書リテラルが1,800行、struct の配列リテラルが1,965要素あります。表の持ち方を変えたところ、型検査に31秒かかっていた表が0.65秒で通るようになりました。
同じ時期に、4本のエージェントに iOS と Workers を並行で実装させていました。各エージェントがビルドするたびに swift-frontend が乱立し、Mac の操作が明らかに重くなりました。こちらも運用ルールを決めて止めています。
本記事は、次のような人に向けて書いています。
Claude Code などで、iOS アプリを複数のエージェントに並行で実装させている人
コード生成で、大きな表（コード表・パス表・マスタデータ）を Swift のソースに埋め込んでいる人
Debug では通るのに、Release のアーカイブだけが終わらない人
有料部分で手に入るものは以下の4つです。
目次（有料部分）
前提：何を作っていて、何が起きたか
症状1：swift-frontend が乱立して Mac が重くなる
症状2：Release のアーカイブが50分終わらない
原因の特定：型検査に時間がかかる式を炙り出す
対処：表をタブ区切りの文字列にして初回アクセス時にパースする
運用：xcodebuild は同時に1本、-jobs 4、ビルドは司令塔が順に回す
チェックリスト
まとめ
自社で作っている一人社長向けの経理アプリで、TestFlight 用の Release アーカイブが50分経っても終わらなくなりました。原因は、コード生成で Swift に埋め込んだ大きな表でした。入れ子の辞書リテラルが1,800行、struct の配列リテラルが1,965要素あります。表の持ち方を変えたところ、型検査に31秒かかっていた表が0.65秒で通るようになりました。
同じ時期に、4本のエージェントに iOS と Workers を並行で実装させていました。各エージェントがビルドするたびに swift-frontend が乱立し、Mac の操作が明らかに重くなりました。こちらも運用ルールを決めて止めています。
本記事は、次のような人に向けて書いています。
Claude Code などで、iOS アプリを複数のエージェントに並行で実装させている人
コード生成で、大きな表（コード表・パス表・マスタデータ）を Swift のソースに埋め込んでいる人
Debug では通るのに、Release のアーカイブだけが終わらない人
有料部分で手に入るものは以下の4つです。
型検査に時間がかかる式を見つけるコマンド1行
巨大なリテラルを「タブ区切りの文字列＋初回アクセス時のパース」に置き換える設計
並列ビルドで Mac を固まらせないための運用ルール
作業前とリリース前に確認するチェックリスト
目次（有料部分）
前提：何を作っていて、何が起きたか
症状1：swift-frontend が乱立して Mac が重くなる
症状2：Release のアーカイブが50分終わらない
原因の特定：型検査に時間がかかる式を炙り出す
対処：表をタブ区切りの文字列にして初回アクセス時にパースする
運用：xcodebuild は同時に1本、-jobs 4、ビルドは司令塔が順に回す
チェックリスト
まとめ