アーカイブと書き出し
.xcarchive、書き出し設定、dSYMを保存します。書き出し前にRelease設定、バージョン番号、ビルド番号を確認しましょう。最終的な.ipaだけを残し、クラッシュ調査に必要なシンボルファイルを失わないようにしてください。
確認ポイント：成果物を一意のコミットとビルド番号にひも付けられること。
ローカルビルドからクラウド配布へ
夜間ビルドを自動化して、
夜間ビルドを自動化して、
仕事用PCは定時にオフ。
複数台の専有物理MacでiOSビルドファームを構築。schemeごとにmacOS runnerへジョブを振り分け、アーカイブ、署名、TestFlightへのアップロードを実行できます。すべてのタスクを1台の仕事用PCに集中させる必要はありません。
ArmRDPでは仮想マシンではなく、Mac miniを1台丸ごと利用できます。3つの構成と5つのロケーションから選べて、料金は1日$21.1から。まず1つのパイプラインを移行し、実際のキューに合わせて拡張できます。
夜間のビルドと配布には、runner・署名・アップロードの設定が必要です。所要時間はプロジェクトや依存関係、ジョブのキューによって異なります。
夜間配布 · ジョブ振り分けの例
1つのリリースラインを3つのビルドに分ける。
schemeごとにジョブを分離し、成果物をノードごとに集約。
-
A
メインアプリ · Releaserunner-app → archive → codesign.ipa
-
B
拡張機能と関連ターゲットrunner-extension → build → test.xcresult
-
C
リリース候補の検証runner-check → simulator → reportテストレポート
- スケジュールの基本
- まずは1台で稼働確認
- 拡張方法
- 独立したrunnerを追加
CI/CDチーム
環境の調査を繰り返すより、ツールチェーンを固定。
クラウドMacをGitLabまたはGitHub ActionsのmacOS self-hosted runnerとして登録。リポジトリはチームの既存の方法で管理し、macOSが必要なjobだけをこの物理ノードに割り当てます。
まずはビルドを再現可能に
Xcodeの完全なバージョン、SDK、コマンドラインツールのパス、依存関係のロックファイルを記録します。複数のXcodeバージョンはxcodesで管理し、jobごとにDEVELOPER_DIRを指定すれば、プロジェクト間でグローバル設定を取り合わずに済みます。
runnerのタグには、OS・ツールチェーン・用途を含めます。例：macos、xcode-pinned、ios-release。リリースjobは信頼できるrunnerだけに割り当て、未審査のブランチは署名情報を扱う実行環境に入れないでください。
導入時は、1台につき重いビルドタスクを1つだけ実行します。クリーンビルド、キャッシュヒット率、メモリ負荷、ディスク使用量の増加を確認してから、並列数を増やすかノードを追加しましょう。キューの長さはマシンの台数だけでなく、キャッシュやジョブの分割にも左右されます。
環境を確認してからアーカイブ
xcodebuild -version
xcode-select -p
xcrun --sdk iphoneos --show-sdk-version
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-archivePath artifacts/App.xcarchive \
archiveAppのワークスペースとschemeは、実際のプロジェクト名に置き換えてください。アーカイブ成果物、ビルドログ、テスト結果はjobごとに保存し、複数のタスクで同じ出力先を使わないようにしましょう。
アプリ配布
アーカイブ・署名・アップロードを、追跡可能な1つのフローに。
App Storeでの公開に向けて、ビルド成果物を対応するコミット、ツールチェーン、署名設定とひも付けます。クラウドMacはビルド環境として利用し、リリース権限と審査用素材は引き続きチームで管理します。
署名と認証情報
配布証明書とプロビジョニングプロファイルは、管理された方法で取り込み、ビルド専用のKeychainを使います。fastlane matchを使う場合はリポジトリへのアクセスを制限し、復号情報はスクリプトに書かず、CIのシークレットストアに保存してください。
確認ポイント：非対話型のjobでcodesignを実行できること。
アップロードと審査用素材
チームが許可した認証情報で成果物をアップロードします。GUIでシミュレーターの画面を確認して審査用素材を作成し、対象デバイス、言語、バージョンをチェックしてください。アップロード完了と審査通過は別の段階です。
確認ポイント：アップロード結果、素材、ログをまとめて保存すること。
リリースjobは、起動するブランチと実行者を制限してください。証明書の期限切れ、プロビジョニングプロファイルの不一致、アップロード権限の不足は、それぞれログを確認して対処します。マシンの構成を増やしても解決しません。
macOSアプリ開発
コマンドラインで実行し、GUIで細部を確認。
専有物理ノード上でmacOSをネイティブに実行。Metalやシミュレーターを使った開発にも対応します。スクリプトやログにはSSH、Xcode・シミュレーター・画面の確認にはVNC画面共有を使い、それぞれの得意分野に応じて活用できます。
リモート実行に向いているタスク
バージョンを固定したビルド、自動テスト、シミュレーターのスクリーンショット撮影、依存関係のインストールは、ローカルの仕事用PCから切り離して実行できます。GUIでの調査が必要な場合は、まず画面上で再現し、繰り返せる手順をスクリプトにまとめましょう。
対象OS、シミュレーターのruntime、Xcodeのバージョンに互換性があるか、事前に確認してください。
個別に検証が必要なケース
リモート画面の応答性は、ネットワーク経路、解像度、エンコード設定によって異なり、ローカルのディスプレイと同じではありません。外部機器、特定の周辺機器、高頻度の操作を伴う作業は、まず1日借りて実際のタスクを試してから移行を判断してください。
AI実験
64GBのユニファイドメモリで、モデルがワークフローに組み込めるか検証。
ArmRDP M4 ProはM4 Pro、64GBのユニファイドメモリ、2TB SSDを搭載。専有環境でのローカルモデルの読み込み、量子化モデルの比較、推論APIの検証に適しています。今後の投資に見合うか判断するためのテストに活用できます。
まず容量、次に速度を確認
モデルファイルのサイズと実行時に必要なメモリは同じではありません。重みに加え、KVキャッシュ、コンテキスト長、実行フレームワーク、他のプロセスに必要なメモリも考慮します。まずは対象モデルの短いコンテキストから試し、最大メモリ使用量とメモリプレッシャーを記録してから、リクエスト数を増やしましょう。
Apple Siliconに対応した推論フレームワークを使い、演算子やモデル形式の互換性を個別に確認してください。ユニファイドメモリがあれば、どんなモデルでも実行できるわけではありません。生成速度もメモリ容量からは判断できないため、実際に使うプロンプト、コンテキスト、出力長で検証しましょう。
実験ごとに記録する4項目
- モデル名、バージョン、量子化形式。
- コンテキスト長、バッチサイズ、最大メモリ使用量。
- 初回読み込み時間と、安定稼働後の応答。
- リクエスト例、出力品質、失敗時のログ。
推論実験と本番リリースのビルドは、メモリの競合で結果に影響しないよう、できるだけ別々にスケジュールしてください。リモートAPIには認証とアクセス制限を設定し、ポートをインターネットに直接公開しないでください。
パイプラインを1つ選んで移行
データを移し、環境をそろえ、最後に実行先を切り替える。
最初からリリースシステム全体を移行する必要はありません。依存関係が明確で、ローカルで安定してビルドできるschemeを1つ選び、ローカルの結果を比較対象にして、次の3段階で検証しましょう。
-
01 · データ
リポジトリと署名に必要な情報を移行
読み取り専用または最小権限の認証情報でリポジトリを取得し、サブモジュール、プライベート依存関係、大容量ファイルを確認します。証明書、プロビジョニングプロファイル、復号キーは個別に管理し、機密ファイルをリポジトリにコミットしないでください。
- 指定したコミットをすべて取得できる。
- ビルドに必要な秘密情報を、管理下で読み込める。
- 成果物とバックアップをノード外に保存する。
合格条件：同じコミットのソースと依存関係がそろっている。
-
02 · ツールチェーン
「自分のPCでは動く」を環境リストに
xcodesでプロジェクトに必要なXcodeをインストールしてバージョンを固定します。Homebrewの依存関係リストとパッケージマネージャーのロックファイルを保存し、対象シミュレーターのruntimeを追加。環境変数と実行パスも記録してください。
- XcodeとSDKのバージョンを照合する。
- まずキャッシュを使わずにビルドする。
- DerivedDataとキャッシュをプロジェクトごとに分離する。
合格条件：手動実行で期待どおりの成果物を得られる。
-
03 · CI接続
runnerを登録し、リリースラインを1つだけ切り替える
runnerを登録してタグとリポジトリ権限を設定し、最初のパイプラインをクラウドMacに割り当てます。成功を確認したら署名とアップロードの工程を加え、最後に他のschemeや独立ノードへ展開しましょう。
- 最初は1ジョブずつ実行する。
- ログ、テストレポート、シンボルファイルを保存する。
- 失敗時に元の実行環境へ戻せるようにする。
合格条件：無人実行のjobを繰り返し完了できる。
移行中は、クリーンビルド、署名、アップロード、失敗時の再試行をすべて検証できるまで、既存のrunnerを残してください。レンタル期間の終了前に必要なデータを書き出し、ノードのディスクだけを唯一の保存先にしないようにしましょう。
3つの構成から選ぶ目安
ビルド回数で候補を絞り、実際のプロジェクトで構成を決める。
以下は1日あたりのジョブ数をもとにした初期構成の目安であり、処理性能のテスト結果やビルド時間の保証ではありません。大規模なフルビルド1回が、小規模な増分ビルド複数回より負荷の高い場合もあります。1回あたりの所要時間、キャッシュヒット率、最大メモリ使用量を記録し、上位構成への変更かノードの追加を検討しましょう。
| 1日のジョブ数の目安 | 初期構成とスペック | 優先して確認すること | 日単位でレンタル |
|---|---|---|---|
| 1～5回 一時的な検証、単一プロジェクトでの導入 |
ArmRDP M4 Base M4 / 16GB / 256GB |
まずアーカイブから署名までの一連の流れを確認。依存関係、DerivedData、成果物がディスク容量をどの程度使うかもチェックしましょう。 | $21.1/日M4 Baseを借りる |
| 6～20回 継続的インテグレーション、頻繁なイテレーション |
ArmRDP M4 Plus M4 / 24GB / 512GB |
コンパイルとテストを同時に実行したときのメモリ負荷を確認。まずキャッシュを最適化し、複数のrunnerが必要か判断しましょう。 | $41.4/日M4 Plusを借りる |
| 21回以上 複数ターゲット、高負荷タスクの検証 |
ArmRDP M4 Pro M4 Pro / 64GB / 2TB |
大規模プロジェクトやモデル実験に必要なリソースを確認。ボトルネックがキュー待ちなら、独立したタスクを複数のノードに分散しましょう。 | $59.5/日M4 Proを借りる |
ノードとレンタル期間を合わせて検討
5つのロケーションはシンガポール、日本（東京）、韓国（ソウル）、香港、米国西部で、すべてのロケーションで3つの構成を利用できます。GUIでの操作が中心なら、チームからノードへの接続性を比較しましょう。無人ビルドでは、リポジトリ、依存関係のダウンロード、成果物のアップロード経路も確認してください。利用可能な構成は、コントロールパネルに表示される最新情報をご確認ください。
検証は1日単位から始められます。定期的にリリースするようになったら、週・月・四半期の料金を比較しましょう。支払い方法はUSDT-TRC20とVisa / Mastercard / Amex（Stripe）に対応。米ドルでの決済となり、実際に利用できる決済方法はバックエンドの応答に基づきます。
まず1日借りて、実際のパイプラインを検証。
schemeを1つ、署名設定を1組、明確な合格基準を用意してください。アーカイブ、署名、配布まで確認できたら、他のタスク用にノードを追加しましょう。