Icon Composer vs Asset Catalog：2026年のAppアイコンの選び方

既存アプリのAppアイコンをIcon Composerへ置き換えたら、旧OSでブランド表示が変わる可能性があります。

2026年9月時点の最短判断は、新規アプリでiPhone、iPad、Mac、Apple Watchを主対象にし、レイヤー素材で再設計できるならIcon Composer、旧OSとの見た目を維持する必要があるか未対応プラットフォームを含むならAsset Catalogです。既存アプリは、今週は本番ブランチを変更せず、分離ブランチでアーカイブ検証を行ってください。

この記事を読むべき開発者

新規アプリで複数のAppleプラットフォーム向けアイコンを整備し、サイズや外観ごとの素材管理を減らしたい独立開発者向けです。

既存ブランドの表示を守りたい開発者、またはMacのレンタル環境や自動ビルドで新形式のアーカイブとアップロードを確認したい小規模チームにも適しています。

なお、2026年9月6日時点でIcon Composerと関連ドキュメントはAppleから正式に提供されていますが、Xcode 27とプラットフォーム27はリリース前の段階です。最終版の挙動として断定せず、Appleの開発者向けリリース記録とXcode Release Notesを確認して判断します。

最初に決めるべきはデザインではなく、置き換えの影響です

Icon Composerは、Asset Catalogに自動的に追加される単なる別形式の素材ではありません。AppleのXcode公式設定手順では、Icon Composerファイルをプロジェクトに加えると、既存のAppIcon asset catalogを置き換える扱いが説明されています。

このため、選択は「どちらの編集画面が便利か」ではなく、次の順番で決めます。

• 新規プロジェクトで、対象がiPhone、iPad、Mac、Apple Watch中心である場合は、Icon Composerを第一候補にします。
• 旧OSでも過去のアイコンと同じ見た目を保つ必要がある場合は、Asset Catalogを維持します。
• iPhone、iPad、Mac、Apple Watch以外の対象や、複雑な公開経路を含む場合は、先に両方式を検証し、必要な資産を削除しません。
• 既存アプリでは、いきなり本番ブランチを置き換えず、分離ブランチと非公開アーカイブで確認します。

AppIconはIcon Composerへ移行しなければならないのでしょうか。
いいえ。Appleが全アプリに移行を強制したという確認はありません。Asset Catalogを使い続ける必要があるケースも、Appleの公式説明に残されています。移行の理由は「新しいから」ではなく、対象OS、既存ブランド、公開工程が新形式に適合するかで決めます。

新規アプリは、レイヤー素材を用意できるかで評価します

Icon Composerが向くのは、単一の完成画像を各サイズへ切り出すより、前景や背景などのレイヤーを基に複数の外観へ展開したいプロジェクトです。Liquid Glassを含む新しい視覚表現を採用する場合でも、デザイン上の提案と、実際にビルドへ含まれる資産の確認は分けて考えます。

採用前に、次の条件を満たすか確認します。

• 既存の平面画像をそのまま流用せず、必要なレイヤー素材を再設計できる。
• 対象プラットフォームごとの表示差を許容できる。
• Xcodeプロジェクトのターゲット設定とIcon Composerファイルの関連付けを管理できる。
• シミュレーターだけでなく、対応する実機または配布前ビルドで表示を確認できる。
• アーカイブ内に期待するアイコンが含まれていることを確認できる。

Icon Composerのプレビューが正常でも、ターゲット設定の誤り、ソースファイルの未追跡、別スキームのビルド設定によって公開用アーカイブが異なることがあります。したがって、編集画面の見た目だけでは合格にしません。

既存アプリは旧版の表示を守れるかを先に比べます

Asset Catalogを使って長く運用してきたアプリでは、アイコンがブランド資産やストア掲載素材と結び付いています。Icon Composerへ置き換えた場合、旧システムではビルド時に生成された類似表示が使われる可能性があり、過去のアイコンと完全に同じになるとは限りません。

Icon Composerで作ったアイコンは旧版iOSでどう表示されますか。
旧版システムで現行アイコンを維持する必要がある場合、AppleはAsset Catalogを継続使用するよう案内しています。したがって、対応OSの最低バージョンだけを見て判断せず、旧版iOS、現在のiOS、暗色表示、単色表示を同じアプリのブランチで比較します。Appアイコンに関するHuman Interface Guidelinesも、最終デザインの確認資料として併用してください。

既存アプリでは、次のような場合にAsset Catalogを残す判断が堅実です。

• 旧端末上のアイコンが広告、サポート資料、ブランドガイドラインと一致していなければならない。
• ストア審査前に表示差を許容できない。
• アイコンの再設計に必要なレイヤー素材が存在しない。
• 最低対応OSや公開対象がIcon Composerの想定範囲から外れている。

注意：Icon Composerファイルと既存AppIcon asset catalogが自動的に共存するとは考えないでください。移行前に、どのターゲットがどの資産を参照するかをプロジェクトファイルとアーカイブで確認します。

多平台対応では、ひとつのファイルに集約しすぎないでください

多平台アプリはIcon Composerファイル1つだけで管理できますか。
iPhone、iPad、Mac、Apple Watchを主対象とする構成では、Icon Composerを中心に設計できる可能性があります。ただし、製品が別のAppleプラットフォームや異なるアイコン資産形式も必要とするなら、未対応の資産まで削除してはいけません。

ここでの判断基準は、次の3点です。

1. 製品の対象プラットフォーム一覧に、Icon Composerで扱う対象だけが含まれているか。
2. 各ターゲットのビルド設定が、正しいアイコン資産を参照しているか。
3. プラットフォーム別のアーカイブを展開し、実際に期待するアイコンが入っているか。

「ファイルを1つにできる」ことは管理上の利点ですが、公開対象を減らしてまで達成する目標ではありません。複数方式を残す場合は、どのターゲットがどの資産を使うのかをREADMEやビルド設定に記録しておくと、後のXcode更新時に誤削除を防げます。

代替アイコンは、見た目より実行時の関係を確認します

主アイコンの移行だけでなく、alternate app iconsも別に点検します。ファイル名、ビルド設定、実行時の切り替え処理が一致していなければ、主アイコンだけ表示できても季節限定アイコンや購読者向けアイコンで失敗します。

静的な代替アイコンが少数なら、Asset Catalogを維持する方が変更範囲を抑えやすい場合があります。一方、キャンペーンやテーマ切り替えで多くのアイコンを管理する場合は、Icon Composerのレイヤー設計が運用負担を減らす可能性があります。ただし、これは機能上の優劣ではなく、素材の作り方とリリース頻度を含めた判断です。

代替アイコンの設定は、Appleのalternate app icons設定資料に沿って、標準アイコン、少なくとも1つの代替アイコン、再インストール後の復元状態、公開用ビルドを確認します。

遠隔Macと自動ビルドでは、次の順で隔離検証します

ローカルMacで表示できたことだけでは、遠隔のビルド環境や無人ジョブで安定している証拠になりません。まず使用するmacOS、Xcode、Icon Composer関連ツールの組み合わせがサポート範囲にあるか、Xcodeのシステム要件と更新済みの公式資料で確認します。

そのうえで、次の手順を実行します。

1. Icon Composerファイル、関連素材、プロジェクト設定をバージョン管理へ追加します。
2. 本番とは別のブランチとスキームを作り、既存Asset Catalogをすぐに削除しない状態で比較対象を残します。
3. ローカルのXcodeでクリーンビルドを行い、シミュレーターと対象実機で通常、暗色、単色の表示を確認します。
4. 署名を伴わないビルドで、ターゲットごとの資産参照と生成物を確認します。
5. 同じコミットを遠隔Macへ渡し、コマンドラインからアーカイブを作成します。
6. アーカイブを展開し、iPhone、iPad、Mac、Apple Watchそれぞれの対象に期待するアイコンが含まれるか確認します。
7. 非公開のテスト配布またはアップロード手前まで進め、ローカルと遠隔で設定差がないか比較します。
8. 失敗時にAsset Catalogへ戻せるコミットを保持したまま、Xcodeやプラットフォームの更新後に再評価します。

遠隔Macを使う場合は、ファイルが本当にビルドユーザーから読める場所にあるか、環境変数やスキームがローカルと一致するかも確認対象です。自動化の構成を見直す場合は、GitHub Actions向けMac Runnerの固定運用に関するガイドも関連します。

経験上、アイコン移行の失敗はデザインファイルそのものより、対象ターゲットの取り違え、別スキーム、アーカイブに含まれない未追跡ファイルで起きやすいものです。合否はプレビューではなく、公開用アーカイブで判定してください。

今週実施する採用判定チェック

以下をすべて実行し、チェック数ではなく、未解決項目の種類で結論を出します。

• [ ] 対応するプラットフォームと最低OSを一覧化した。
• [ ] 新規アプリか、既存ブランドを維持するアプリかを分類した。
• [ ] Icon Composerのレイヤー素材を再設計できるか確認した。
• [ ] 旧版iOSで過去のアイコンと表示が一致するか比較した。
• [ ] 暗色、単色、通常表示をシミュレーターまたは実機で確認した。
• [ ] 主アイコンと代替アイコンのファイル名、設定、実行時切り替えを確認した。
• [ ] ローカルのクリーンビルドと遠隔Macのアーカイブを同じコミットで比較した。
• [ ] アーカイブ内のターゲット別アイコンを確認した。
• [ ] 失敗時にAsset Catalogへ戻せる分離コミットを保持した。
• [ ] Xcode 27の最終版、Icon Composer更新、App Store Connect要件変更を再確認する日程を決めた。

判定は次の3つで十分です。新規で多平台対応し再設計できるなら「移行」、旧版の見た目を守る必要があるなら「Asset Catalog継続」、対象が複雑で証拠が足りないなら「当面は両方式を分離して検証」です。

現状のローカル環境だけでこの検証を進めると、必要なmacOSやXcodeを入れられない、ストレージを一時的に消費する、公開用アーカイブと開発用ビルドの差を確認できない、といった制約が出ます。特に既存アプリの本番ブランチで直接移行する方法は、旧OS表示と代替アイコンの回帰を同時に引き起こしやすいため、費用だけでなく切り戻し時間も見積もるべきです。

そのため、手元に適切な環境がない場合は、完全な権限で使えるJexMacのMacレンタルを一時的な検証先にし、実プロジェクトの隔離ブランチでビルド、アーカイブ、アイコン表示、アップロード手前まで確認してから正式移行を決める方法が現実的です。料金条件を確認する場合はJexMacの料金案内、環境の接続や運用条件はJexMacのヘルプで確認できます。長期にわたり安定した高負荷ビルドを続ける場合や、物理デバイス接続が必須の場合は自前のMacが適しますが、今回のような移行前の短期検証では、購入前に必要な証拠だけを集められる遠隔Macの方が判断を誤りにくいです。