🛠️ Xcodeを一度も開かずにMacとiOSアプリを出荷した人の構成 — XcodeGen+xcodebuild+エージェントで公証まで

Macアプリを作りたい気持ちと、Xcodeを開きたくない気持ちは、両立する。

冗談ではなくて、コーディングエージェント中心の開発に慣れた身体には、IDEのGUIがだんだん「エージェントが触れない領域」に見えてくる。ターミナルとエディタで完結する開発はエージェントに委任できるが、Xcodeのビルド設定画面をポチポチする作業は委任できない。Scott Willseyがこの問題を最後まで突き詰めて、Xcodeを一度も開かずにmacOSメニューバーアプリのTZedとiPhoneアプリのMikanRemoteを出荷した記録を公開していた。

構成の要はXcodeGen

最大の障害は .xcodeproj だ。あの巨大で不透明なプロジェクトファイルはGUIで編集する前提で作られていて、手書きもLLMによる生成も事故りやすい。Willseyの答えはXcodeGen。プロジェクト定義をYAMLで書き、.xcodeproj は毎回そこから機械生成する。

# project.yml — これが真実の源。.xcodeprojは生成物
name: TZed
targets:
  TZed:
    type: application
    platform: macOS
    sources: [Sources]
    settings:
      base:
        CODE_SIGN_STYLE: Automatic

これ、うちのWFビルドと同じ思想なんですよね。人間(とAI)が触るのは小さな宣言ファイルだけで、機械が嫌がる巨大ファイルはビルドで再生成する。GUIツールの成果物を直接編集しない。

日常のビルドは xcodebuild に CODE_SIGNING_ALLOWED=NO を付けて署名をスキップし、速度を稼ぐ。エージェントが書いてはビルドするループがここで回る。

公証までスクリプト1本

macOSアプリ配布の関門はGatekeeperだ。署名し、公証(notarization)に出し、ステープルで貼り付けるという儀式を通らないと、ユーザーの初回起動で警告が出る。Willseyはここも release.sh 1本に畳んだ。

./scripts/release.sh
# archive → Developer ID書き出し → 公証 → ステープル → インストール

事前準備はDeveloper ID証明書をログインキーチェーンに一度入れておくことだけで、あとは signingStyle: automatic が面倒を見る。entitlementsも署名時に実チーム識別子で効くので、CLIだけで完結する。

そして仕上げがこの記事の一番今っぽいところで、この手順一式をCLAUDE.mdに文書化して、エージェントに実行させている。「リリースして」で公証まで走る。人間向けのREADMEを書く感覚で、エージェント向けの運用手順書を書く。手順書がそのまま実行可能な自動化になる時代です。

正直な注記も添えておく

タイトルの「Xcodeを開かない」は看板に偽りなしだが、Xcodeのインストール自体は要る。xcodebuildもSDKも公証ツールもXcode同梱物なので、消せるのはGUIを開く工程だけだ。あと記事の範囲はDeveloper ID配布と実機開発が中心で、App Store提出のフローは詳しく書かれていない。Interface Builder前提の複雑なUI(Storyboard資産のあるプロジェクト)をこの構成に載せ替えるのも、また別の戦いになると思う。

それでも、SwiftUI+小さなアプリならこの構成は現実的に回ることが、出荷済みアプリ2本で証明されている。日本語圏にもxcodebuild自動化の記事はあるが、エージェント駆動で公証まで通した実録はまだ少ない。

IDEが囲い込んでいた領域が、宣言ファイルとCLIとエージェントの組に少しずつ解体されていく。次に解体されるGUIはどれだろう。自分はFigmaのオートレイアウト設定あたりだと踏んでいるんですが、どう思いますか。