2026年折りたたみiPhone UltraのApp素材

症状：折りたたみiPhone向けに全素材を作り直すべきか迷う

2026年8月8日時点で、AppleがApp Store Connectに指定しているiPhone用スクリーンショットは、6.9インチや6.5インチなど既存のディスプレイ区分です。Appleの公開仕様には、折りたたみiPhone Ultra専用の素材スロットや、折りたたみ状態と展開状態を分けて提出する規定は記載されていません。(developer.apple.com)

最短の解決策は、伝聞の画面サイズで一括再制作しないことです。 現行素材はApp Store Connectの仕様に沿って維持し、横幅が増えたときに価値を示せる画面だけ候補化します。可変キャンバス、差し替えやすい文言、発表後に再収録できる工程を先に用意してください。

この記事は、2026年秋に新バージョンを提出する公開担当者、複数言語のストア素材を管理するデザインチーム、複数の掲載パターンを運用する担当者向けです。真機をまだ持っていない開発者やテスト担当者にも、今できる準備と待つべき作業を切り分けます。

注意： 折りたたみiPhone Ultraという名称、2026年秋の発表、量産状況は報道やサプライチェーン情報に基づく伝聞です。Appleが正式名称、発売日、画面仕様、素材要件を公表するまでは、スクリーンショット制作の根拠にしないでください。(macrumors.com)

現行素材を残す判断

App Store Connectの基準

Appleは現在、iPhone向けスクリーンショットを1枚以上10枚以下、JPEG、JPG、PNGで登録できると案内しています。透過やアルファチャンネルは使用できません。6.9インチ用の画像がない場合、対応する高解像度画像が縮小利用される仕組みもあります。(developer.apple.com)

ここで重要なのは、新しい端末の噂と、ストアに提出する画像の規格は別の管理対象だという点です。折りたたみ構造が本当に登場しても、App Store Connect側に専用区分が追加されるとは限りません。Appleが既存の高解像度素材を縮小して表示する方式を続ける可能性もありますが、これは現時点では推測です。

次の素材は、今すぐ捨てる必要がありません。

• ログイン、検索、決済、通知など、画面幅が変わっても価値が変わりにくい画面
• 端末の外枠やヒンジを描いていない、実際のApp画面を中心にした素材
• 複数言語で共通利用している機能説明用の画像
• 既存のiPhone向け高解像度素材を基準にした一般的な機能紹介

反対に、固定幅のカードだけで構成された画面、横幅を広げると情報量が増えるダッシュボード、左右の一覧と詳細を同時に見せる画面は、候補素材として分けておく価値があります。

横幅を見せる候補画面

折りたたみAppの素材を準備するとき、すべての画面に展開状態を見せる必要はありません。幅が増えたことで、ユーザーの操作や理解が具体的に良くなる画面を選びます。

候補にしやすいのは、次のような機能です。

• 編集画面：ツールバーと編集対象を同時に表示できる
• ダッシュボード：複数の指標や一覧を横並びで比較できる
• 読書・文書画面：本文と目次、注釈を同時に確認できる
• 地図画面：地図と検索結果、詳細カードを並べられる
• 多欄ツール：一覧、詳細、操作パネルを段階的に表示できる

ただし、伝聞の画面比率や端末外枠を使った合成画像は避けてください。実在しない端末フレームや、Appleがまだ提供していないシステム画面を入れると、発表後の作り直しだけでなく、掲載内容の正確性にも問題が出ます。

iOS 27では、iPhone AppがiPhoneミラーリングやiPad上でサイズ変更可能な環境に対応し、実行時の利用可能なサイズに応じて画面を調整することが求められています。Xcode 27では、サイズを変えられるシミュレーターやプレビューを使った確認が案内されています。(developer.apple.com)

そのため、今の候補画面では「折りたたみ状態」を再現するより、幅が狭いときに情報が崩れず、幅が広いときに追加の価値を自然に表示できるかを確認します。これは将来の専用素材を保証する作業ではなく、画面設計の破綻を早く見つける作業です。

画像制作フローの分離

一括再制作より先に、スクリーンショットの生成工程を点検してください。特に次の項目がテンプレートへ直接書き込まれている場合、発表後の修正範囲が広がります。

• 端末名を画像内に固定している
• ピクセル寸法をスクリプトへ直書きしている
• 縦向きと横向きの判定をファイル名だけで行っている
• 翻訳文の位置を座標で固定している
• 収録、端末フレーム、文字組み、書き出しを一つの処理にまとめている

5段階に分けると、差し替えやすくなります。

1. 画面収録：実際のApp画面を、言語と表示状態ごとに取得します。
2. 素材情報の付与：言語、向き、画面種別、ビルド番号をファイル名や管理情報に記録します。
3. 端末表現の追加：必要な場合だけ端末フレームや背景を適用します。
4. 文字とレイアウトの配置：見出し、補足文、安全領域を可変レイヤーとして扱います。
5. 規格別の書き出し：Appleが指定した寸法を確認してから、最終画像を生成します。

Appleの現行仕様では、6.9インチ用の縦画像として1260 x 2736ピクセル、横画像として2736 x 1260ピクセルが示されています。ただし、これは現在の対象機種向けの値であり、折りたたみiPhone用の将来規格ではありません。伝聞の解像度をCI/CDや書き出しスクリプトへ組み込まないでください。(developer.apple.com)

Xcode 27の可変サイズ検証環境を使う場合も、画面を取得する段階と、ストア用画像へ整える段階を分けて保存すると安全です。公開前の確認作業をMac上でまとめたい場合は、収録用の環境と書き出し手順を別々に管理してください。

多言語素材と製品ページの増幅要因

再制作の負担は、端末数よりも言語数、画像セット数、カスタムプロダクトページの分岐数で増えます。英語、日本語、韓国語など複数のローカライズを持つAppでは、1枚の画面変更が各言語の文言、改行、余白、画像内ラベルへ波及します。

さらに、カスタムプロダクトページで訴求別の画像セットを管理している場合、同じ画面を機能別に再配置する必要があります。具体的な工数や費用はチームの制作方法で変わるため、伝聞から一律の数字を置くべきではありません。

先に固定するのは、画像そのものではなく次の設計情報です。

• 1枚ごとの主な訴求
• 画面内で変更してよい領域
• 翻訳によって伸びる見出しの最大幅
• 縦向きと横向きで残す操作要素
• 発表後に再収録する画面の優先順位

少数の画像だけを管理するAppなら、公式発表を待っても問題になりにくいでしょう。反対に、多言語素材や複数の製品ページを持つAppは、今の段階でテンプレートを分離しておく方が安全です。画像を先に全部作るのではなく、変更点を限定するために準備します。

秋の提出スケジュール

App Store Connectでは、スクリーンショットをアップロードできるのは、提出準備中、レビュー待ち、バイナリ不備、却下、メタデータ却下、開発者側での取り下げなど、対象バージョンが特定の状態にある場合です。承認後に素材を更新するには、新しいバージョンを作成する必要があります。(developer.apple.com)

したがって、発表日と素材変更可能日を同じ予定表に置かないでください。次のように分けます。

• 現在：既存素材を維持し、候補画面と可変テンプレートを準備する
• Appleのイベント招待後：発表日とSDKの確認予定を更新する
• 正式発表後：公式端末名、素材区分、受け入れ寸法を確認する
• SDK検証後：iOS 27とXcode 27で候補画面を再収録する
• デザイン確認後：多言語、向き、文字切れ、製品ページ差分を確認する
• 提出前：App Store Connectへ登録し、審査用バージョンとの関係を確認する

折りたたみiPhoneが発表されても、発売時期やApp Store Connectの仕様変更が同じ日に確定するとは限りません。報道でも、発表と発売が分かれる可能性が指摘されています。(macrumors.com)

発表後の素材受け入れチェック

正式情報が出たら、次の順番で確認してください。画像制作を始める前に、登録条件を確定させることがポイントです。

• [ ] Apple公式ページに記載された端末名を確認する
• [ ] App Store Connectに新しい端末区分や専用スロットが追加されたか確認する
• [ ] 縦向き、横向き、それぞれの受け入れ寸法を確認する
• [ ] 高解像度画像からの縮小利用が可能か確認する
• [ ] 画像形式、透過、アルファチャンネルの条件を確認する
• [ ] 折りたたみ状態と展開状態を別々に提出する規定があるか確認する
• [ ] 画像が実際のApp画面を正確に示しているか確認する
• [ ] 幅広い表示が、単なる空白ではなく機能上の価値を示しているか確認する
• [ ] 各言語の見出し、改行、画面内ラベルを確認する
• [ ] 新バージョンの提出が必要か、既存バージョンの編集範囲で足りるか確認する

Appleが専用規格を追加していなければ、既存の最高解像度素材を優先して整えるのが合理的です。折りたたみ状態と展開状態の独立セットを、噂だけを根拠に作る必要はありません。

迷ったときの三つの出口

判断を三分類にすると、公開準備が止まりません。

そのまま使う

• 主な訴求が画面幅に依存しない
• 現行仕様の画像がすでに揃っている
• Appleの専用スロットが確認できていない

候補を先に作る

• 編集、地図、読書、ダッシュボード、多欄操作が中心
• 幅広い表示で操作価値を説明できる
• 多言語や製品ページが多く、再制作の波及が大きい

発表後に作り直す

• 端末名や解像度を画像へ焼き込んでいる
• 新しい素材区分がApp Store Connectに追加された
• Appleが折りたたみ状態と展開状態の提出を明示した
• 既存画像では幅広い操作価値を正確に表現できない

現在の環境がローカルMacだけで、iOS 27の可変サイズ確認や自動収録を進めにくい場合は、Macの開発環境と運用方法を確認するところから始めてください。関連する運用条件を整理する際は、MacHTMLの日本語案内も参照できます。短期の検証環境を用意する場合は、購入よりもレンタルの方が、発表後の一時的なSDK確認や素材収録に合わせやすいことがあります。

ただし、長期にわたる高負荷のビルド、物理アクセサリの接続、常時占有するCI運用では、自前のMacや固定環境の方が適する場合もあります。手元の環境は初期費用がかかり、更新や保守も必要です。一般的なクラウド環境はMac固有の画面収録や署名設定で制約が出やすく、遠隔操作では映像品質の確認に手間がかかることがあります。発表後の短期検証、複数のXcode構成、チーム間の一時共有が目的なら、MacHTMLのMacレンタルを比較対象に入れる価値があります。