macOS Tahoe 26.4以降がIcon Composer単体版の動作条件です。これはAppleの公式案内に記載されています（Icon Composer公式ページ）。したがって、新規プロジェクトはIcon Composerを直接採用し、既存アプリは旧AppIconをすぐ削除せず、移行用ブランチで新旧を比較してください。切り替え条件は、シミュレーター、実機、Archive、TestFlightの4段階を通過することです。
01 このチェックリストの対象
iOS 27またはmacOS 27向けに新しいアイコンを作る独立開発者が対象です。設計ファイルから配布ビルドまで、どこで確認すべきかを整理します。
既存のAppIcon資産を保守している場合は、置き換え、継続利用、双軌検証の判断に使えます。リモートMacや自動ビルド環境を使う小規模チームにも向いています。
最終更新：2026年8月29日。Xcode 27 beta 6の公開状況は、Apple DeveloperのXcodeリリース記録で確認しています。正式版の挙動や提出条件は、後続のリリースノートで再確認してください。
02 最初に分けるべき4種類のファイル
編集画面でアイコンが正しく見えても、TestFlightで旧アイコンが表示されることがあります。多くの場合、デザインの問題ではなく、参照先または成果物の確認範囲がずれています。
Icon Composerのプロジェクト、AppIcon資産、アプリBundle内のリソース、ストア掲載用のマーケティング素材は同じものではありません。
| 種類 | 役割 | 受け入れ時の確認 |
|---|---|---|
| 分層素材 | SVGやPNGなどの元データ | レイヤー順、透明部分、明暗外観の意図 |
| Icon Composerファイル | 多層アイコンと外観を管理する作業ファイル | プロジェクト内のパス、バージョン管理、ターゲット所属 |
| AppIcon | Xcodeがアプリのアイコンとして参照する資産 | ビルド設定とアイコン名の一致 |
| Bundle内リソース | Archiveやインストール後に実際に含まれるデータ | 旧資産が残っていないか、期待するアイコンが入っているか |
| マーケティング素材 | App Store掲載画面などで使う宣伝用画像 | アプリ本体のアイコンと混同しないこと |
AppleのXcode公式接続手順でも、Icon Composerファイルをプロジェクトへ追加し、ターゲットとの関連を確認する流れが示されています。
03 新規プロジェクトは直接採用する
新しく作るアプリなら、旧AppIconとの互換性を抱え込まずにIcon Composerを基準にできます。ただし、エディターのプレビューを成功判定にしてはいけません。
第一歩：素材を外観別に準備する
Default、Dark、Monoで見分けられる分層素材を用意します。単に一枚のマーケティング画像を読み込むのではなく、背景、主形状、細部などを役割ごとに整理してください。
小さい表示で細部が消える場合があります。明るい背景と暗い背景で輪郭が埋もれないか、Monoで主要なシルエットが残るかを確認します。
第二歩：Icon Composerファイルを作成する
Icon Composerで新しいアイコンを作成し、分層素材を割り当てます。ファイル名は後の自動処理でも扱いやすい命名にしてください。
プロジェクトに追加した後、Xcodeのファイル一覧に見えているだけで安心しないでください。対象ターゲットに所属していることを確認します。
第三歩：App Icon設定を照合する
Xcodeのターゲット設定で、アプリアイコンの参照名を確認します。Icon Composerファイルの名前と、ビルド設定が参照するAppIcon名が一致していなければ、読み込み済みでも生成物は変わりません。
過去のAppIconを残している場合は、どちらが優先される構成なのかを記録します。曖昧な状態で複数のアイコン資産を置くと、ローカル表示とArchiveの結果が分かれます。
第四歩：3つの外観を個別に確認する
Defaultだけで合格にしないでください。DarkとMonoも、シミュレーターでインストールしたアプリのホーム画面から確認します。
編集画面、ビルド後のホーム画面、配布ビルドの表示は別々に記録します。スクリーンショットにはプロジェクト名やBundle IDなどの機密情報を含めないようにします。
04 既存アプリは双軌検証から始める
既存アプリでは、Icon Composerファイルが旧AppIcon資産を置き換える関係になる可能性があります。そのため、メインブランチでいきなり削除するのは避けてください。
まず移行用ブランチを作成します。旧AppIconを残した状態で新しい構成を加え、表示結果とArchiveの差分を比較します。
旧システムで従来の視覚表現を維持する必要があるアプリでは、継続利用のほうが安全な場合があります。新しい外観を優先する場合でも、最低対応OSでの見え方が許容範囲かを確認してから切り替えます。
Appアイコン設定に関するXcode公式説明を参照し、次の記録をブランチに残してください。
- 変更前後のビルド設定
- 旧AppIconと新しいIcon Composerファイルの配置
- 最低対応OSでの表示結果
- Archiveに含まれるアイコン資産
- 問題発生時に戻せるコミット
- TestFlightで処理されたビルドの識別情報
05 多平台プロジェクトは共通化しすぎない
iPhone、iPad、Mac、Apple Watchを同じアプリで扱う場合、単一の分層デザインが全てのプラットフォームで明瞭とは限りません。
マスク形状、表示サイズ、外観切り替えの扱いが異なるためです。共有できるのはレイヤー構造やブランド要素であり、細部の余白やコントラストまで完全に固定できるとは限りません。
| 対象 | 共通化しやすい部分 | 個別に確認する部分 |
|---|---|---|
| iPhone | 主形状、背景、ブランドカラー | 小さい表示での輪郭、Dark、Mono |
| iPad | 主形状とレイヤー構成 | マスク後の余白、細部の視認性 |
| Mac | ブランド要素、外観の設計意図 | デスクトップ上のサイズ感、立体感 |
| Apple Watch | 主形状の簡略版 | 小型表示での判別性、細い線 |
| visionOSなど | 既存設計の考え方のみ | 対応範囲と専用規則を公式資料で確認 |
visionOSなど、同じ手順に含まれるか確認できていない対象は、自己判断で対応範囲を広げないでください。対応先の公式仕様に従って別途確認します。
06 リモートMacの自動ビルドで見る場所
リモートMacを使う場合、ローカルのXcode画面で開けることより、非対話型のArchiveが再現できることが重要です。Icon Composer公式ページが示すmacOS Tahoe 26.4以降の条件も、接続先の環境で確認してください。
次の順で調べると、原因を切り分けやすくなります。
- 接続先のmacOSとXcodeのバージョンを記録します。
- Icon Composerファイルがバージョン管理の対象か確認します。
- 同期後の実パスと、プロジェクトが参照するパスを比較します。
- Xcodeのターゲットメンバーシップを確認します。
- App Icon設定の名前とファイル名を照合します。
- GUI操作ではなく、同じ接続先でコマンドラインArchiveを実行します。
- actool、ibtool、Archiveのログを保存します。
- 成果物を展開し、旧アイコンが残っていないか確認します。
ファイルが見つからない場合、最初から全キャッシュを削除するのは得策ではありません。キャッシュを消すと一時的に成功しても、同期漏れやターゲット設定の誤りが隠れるためです。
自動ビルドを組む前に、Xcode 27のリモートMac構築と受け入れ確認も確認しておくと、ツールチェーンと接続環境を別々に点検できます。
07 4層で行うリリース判定
Icon Composerの接続確認は、次の順序で進めます。前段を飛ばしてTestFlightだけを見ると、原因を特定しにくくなります。
| 段階 | 何を見るか | 不合格時の判断 |
|---|---|---|
| シミュレーター | Default、Dark、Monoの基本表示 | 素材、外観、マスクを再確認 |
| 実機 | 最低対応OSを含む実際のホーム画面 | OS差を許容できるか判断 |
| Archive | 配布用成果物に正しい資源が入るか | ビルド設定とBundle内容を調査 |
| TestFlight | 処理済みビルドのインストール後表示 | 旧資産参照や配布後の差異を調査 |
App Store Connectでは、アップロードしたビルドが処理中、検証失敗、利用可能などの状態に分かれます。状態の意味はApp Store Connectのビルドアップロード状況で確認してください。
リリース担当者向けチェックリスト
- [ ] 新規プロジェクトか既存アプリかを記録した
- [ ] 既存アプリでは移行用ブランチを作成した
- [ ] Icon Composerファイルがバージョン管理に含まれている
- [ ] 対象ターゲットのメンバーシップを確認した
- [ ] App Icon設定の参照名を照合した
- [ ] Defaultの表示をシミュレーターで確認した
- [ ] Darkの表示をシミュレーターで確認した
- [ ] Monoの表示をシミュレーターで確認した
- [ ] 最低対応OSの実機またはシミュレーターで確認した
- [ ] Archive内のアイコン資産を確認した
- [ ] TestFlightでインストール後の表示を確認した
- [ ] 旧AppIconを削除する条件と回退方法を記録した
- [ ] プロジェクト名、Bundle ID、端末名、ログの機密情報を隠した
- [ ] App Store Connectのビルド処理状態を確認した
| プロジェクトの状態 | 推奨する初手 | 旧資産の扱い |
|---|---|---|
| 新規アプリ | Icon Composerを基準に構成 | 不要な旧AppIconを増やさない |
| 既存アプリで視覚変更が不要 | 現行AppIconを継続 | 削除せず現行ビルドを基準にする |
| 既存アプリで新外観が必要 | 移行ブランチで比較 | 4層確認まで残す |
| 複数プラットフォーム | 共通レイヤーと個別調整を分離 | 対象ごとの回退条件を記録 |
| 自動ビルド環境 | 非対話型Archiveを先に再現 | 同期とターゲット所属を監視 |
| 確認対象 | 合格条件 | 記録する証拠 |
|---|---|---|
| ファイル | 接続先で参照可能 | パス、コミット、同期結果 |
| Xcode設定 | 期待するAppIcon名を参照 | ビルド設定の記録 |
| 表示 | 外観とOSごとの差が許容範囲 | 端末別スクリーンショット |
| Archive | 正しい資源を含む | Archive展開結果 |
| TestFlight | 処理済みビルドで期待どおり表示 | ビルド状態とインストール結果 |
08 よくある確認事項
既存のXcodeプロジェクトにIcon Composerファイルを加える方法
プロジェクトにファイルを追加した後、ターゲットメンバーシップ、App Icon設定、参照パスを順番に確認します。ファイル一覧に表示されることと、ビルドで使われることは同じではありません。
古いAppIconを残したまま移行できるか
移行用ブランチで残して比較できます。ただし、新しいIcon Composer構成が旧資産を置き換える場合があるため、どちらがBundleに入ったかをArchiveで確認してください。
古いiOSで表示が異なる場合の対応
Default、Dark、Monoの処理やマスクがOSによって異なる可能性があります。最低対応OSで許容できない差があるなら、Icon Composerへの完全移行を急がず、旧AppIconを維持します。
リモートMacでファイルが見つからない場合
同期対象、実パス、ターゲットメンバーシップ、App Icon設定を確認します。その後にコマンドラインArchiveを実行し、actool、ibtool、Archiveのログを保存します。
App Store提出前の最終確認
シミュレーター、実機、Archive、TestFlightを順に確認します。編集画面のプレビューだけで公開判断をせず、App Store Connectでビルドが正常処理されたことまで確認してください。
09 現在の環境から切り替える判断
手元のMacだけで進める場合、必要なmacOSとXcodeを同時に維持しにくく、旧AppIconとの比較用環境も占有します。ローカルディスクの消費、複数OSの切り替え、夜間の自動Archive停止が、独立開発者には隠れた負担になります。
特に、Icon Composerの条件を満たす環境を一時的に用意したいだけなら、専用のMacを購入して固定する必要はありません。CALMVPSのMacレンタル料金と利用条件を確認し、移行用ブランチとTestFlight検証だけを分離した構成にすると、導入前の比較を進めやすくなります。
常時同じ負荷で長期間ビルドする場合や、物理USB機器、特定の実機接続を必要とする場合は、自前のMacのほうが適しています。一方、必要なツールチェーンを試す期間や、既存アプリのアイコン切り替えを検証する期間なら、CALMVPSのリモートMacでArchiveとTestFlightまで確認してから、常駐環境を持つか判断する方法が現実的です。
必要なときだけMac環境を確保したい場合は、CALMVPSの日本語向け利用案内から、作業期間と接続方法を確認してください。