業務用のiPhoneアプリや、自社サービスのアプリを持っている会社では、新しいiPhoneが出るたびに「うちのアプリは大丈夫か」を確かめる必要があります。2026年10月23日に発売された折りたたみ型の「iPhone Duo」は、その確認の手間が普段より大きい機種です。開くと内側の大きな画面、閉じると外側の画面にアプリが移り、そのたびにアプリの大きさが変わるためです。
Appleは開発者向けの案内で、画面の大きさや向き、機種を決め打ちしたコードは表示が崩れる原因になると書いています。
Hardcoded screen sizes, fixed orientations, and device assumptions can break layouts, leading to stretched, clipped, or misplaced content.
この記事では、Appleのニュースと準備のページ（Three steps to make your app shine on iPhone Duo）、スクリーンショットの仕様のページをもとに、アプリの保守担当者や発注者が確かめることを整理します。
ビルドに使うSDKで、iPhone Duoでの見え方が変わる
すべてのアプリはiPhone Duoで動きますが、どのSDK（開発キット）でビルドしたかによって、表示のされ方が違います。Appleの準備のページの説明をまとめると次のとおりです。
| ビルドに使ったSDK | 開いたとき（内側の画面） | 閉じたとき（外側の画面） |
|---|---|---|
| iOS 26 SDK以前 | 画面の中央に表示され、周りに余白が残る | ステータスバーとカメラの左側に表示される |
| iOS 27 SDK | 内側の画面の大部分に広がる。右端のステータスバーは避ける | （ページに個別の記載なし） |
| iOS 27.1 SDK以降 | 画面全体を使う最適化された表示。ツールバーやタブバーがステータスバーの下に縦に並ぶ | （個別の記載はなく、画面を移っても一貫した体験になるとだけ書かれている） |
ここで注意したいのは、新しいSDKで作り直すほど、アプリの側の対応が必要になる点です。古いSDKのままなら余白付きで表示されるだけですが、iOS 27.1 SDK以降でビルドすると画面いっぱいに広がり、さらにツールバーやタブバーが縦向きになります。Appleは、iOS 27.1 SDKでビルドしたものを出す前に、バーが縦になっても中身が崩れないか確かめるよう求めています。
表示が崩れやすい書き方
Appleの準備のページは、見直すべき書き方を具体的に挙げています。主なものは次のとおりです。
UIScreen.mainから大きさを取る：iPhone Duoではアプリの大きさが画面の大きさと一致しないことがある。view.boundsやwindow.bounds、SwiftUIならGeometryReaderやonGeometryChangeを使う- 起動時に一度だけ大きさを読む：折りたたみで途中で大きさが変わるため、
layoutSubviewsやviewDidLayoutSubviewsでレイアウトし、大きさの変化にはviewWillTransition(to:with:)を使う UIWindow(frame: UIScreen.main.bounds)でウィンドウを作る：UIWindow(windowScene:)に置き換える- 端末の向きでレイアウトを決める：
UIDevice.current.orientation、statusBarOrientation、interfaceOrientationを使った判断をやめ、使える幅と高さを比べる - 機種やサイズクラスで端末を決め打ちする：
userInterfaceIdiom == .phone/.padでの分岐や、「幅がregularならiPad」という前提をやめる。bounds.height == 844のような特定の機種の大きさとの比較も合わない - 全面に敷く画像や動画：
.scaleAspectFillなどで広い画面に引き伸ばすと、大事な部分が切れることがある
「幅がregularならiPad」という前提は、iPadにも対応しているアプリで特に確かめておきたい点です。Appleは、iPhone Duoやサイズを変えられるiPhoneミラーリングでは、iPhoneのアプリがどんなサイズクラスの組み合わせにもなりうると書いています。iPad向けの画面を出す条件を「regular幅」だけにしていると、その画面がiPhoneにも出ることになります。
手元で書き方を探してみる
Appleは、Xcodeのコーディングアシスタントに「get my app ready for iPhone Duo」と頼むと、上の書き方を探して直し方を示す「スキル」が動くと案内しています。別のコーディングエージェントを使う場合は、ターミナルで xcrun agent skills export を実行してスキルを書き出せるとしています。ただし、Appleはこのスキルで「ほとんどの問題は見つかるが、すべてではない」とも書いています。
Xcodeを使う前の下調べとして、上の一覧を grep で探すこともできます。次の検索は、編集部が準備のページの一覧から作ったものです。
grep -rnE 'UIScreen\.main|UIDevice\.current\.orientation|statusBarOrientation|interfaceOrientation|userInterfaceIdiom *== *\.(phone|pad)|horizontalSizeClass *== *\.regular|bounds\.(height|width) *== *[0-9]+' --include='*.swift' .編集部の検証環境（Linux）で、これらの書き方を含めて作った検証用のSwiftのファイルに実行し、UIScreen.main（2か所）、userInterfaceIdiom == .pad、horizontalSizeClass == .regular、UIDevice.current.orientation、bounds.height == 844 の6行がすべて拾えることを確かめました。公開前の2026年10月27日には、同じ内容のファイルに対してmacOS 26.5.1の grep でも同じ6行が出ることを確かめています。Swiftのコードのビルドや、Xcodeのスキルの動作は確認していません。Objective-Cで書かれた部分や、FlutterやReact Nativeなどで作ったアプリの場合は、それぞれのフレームワークでの書き方に合わせて探し方を変える必要があります。
見つかった箇所は、すべてが問題になるわけではありません。たとえば、UIScreen.main を画面の明るさの調整のために使っているだけなら、レイアウトとは関係がありません。1つずつ、レイアウトの判断に使っているかを確かめます。
確かめる道具
Appleは、大きさの変化を試す方法として次の3つを挙げています。
- Device Hubにある、サイズを変えられるiOSのシミュレーター
- macOS 27のiPhoneミラーリング（ウィンドウを両方向に極端な大きさまで変えて試す）
- Xcode 27.1のiPhone Duoのシミュレーター（ネイティブの体験を試すには最もよい方法とされている）
実機がなくても、シミュレーターで「開く・閉じる」の切り替えと、ツールバーやタブバーが縦になったときの見え方を確かめられます。
2027年4月のスクリーンショットの条件
App Storeに出しているアプリは、ストアのページに載せるスクリーンショットにも期限があります。ただし、Appleの資料の間で書き方が少し違います。
- 10月5日のニュース：「Starting April 2027, any apps or games submitted will need to include screenshots for iPhone Duo.」（2027年4月から、提出するすべてのアプリとゲームにiPhone Duoのスクリーンショットが必要）
- スクリーンショットの仕様のページ：「Starting in April 2027, screenshots will be required for any app using the iOS 27.1 SDK or later.」（2027年4月から、iOS 27.1 SDK以降を使うアプリでスクリーンショットが必要）
公開前に確認した2026年10月27日時点でも、2つの資料の書き方は変わっておらず、どちらが正しい条件かは資料から判断できませんでした。どちらにしても、2027年4月以降にiOS 27.1 SDK以降で提出するアプリには必要になるため、そのつもりで準備しておくのが安全です。仕様のページによると、iPhone Duoのスクリーンショットの大きさは次のとおりです。
- 外側の画面：1398 × 2034ピクセル、または2034 × 1398ピクセル
- 内側の画面：2007 × 2853ピクセル、または2853 × 2007ピクセル
iPhone Duoのスクリーンショットを提出すると、App Storeのページに「iPhone Duoに最適化」を示すバッジが表示されるとしています。
発注者・保守担当者が決めておくこと
ここからは編集部の提案です。外注先にアプリの保守を任せている場合は、次の3点を決めておくと、慌てずに済みます。
- 次のビルドで使うSDKの版：iOS 27.1 SDK以降に上げるのか、上げるならいつか。上げる前に、上の書き方の点検と、縦向きのバーでの見え方の確認を作業に含める
- 点検の範囲：Swiftのコードだけでなく、Objective-Cの部分や、使っている外部のライブラリも含めるか
- スクリーンショットの準備：2027年4月までに、外側と内側の画面のスクリーンショットを誰が作るか
ネイティブアプリの保守にかかる手間や、クロスプラットフォームとの比べ方は業務用スマホアプリを外注する前にで、ネイティブとクロスプラットフォームの選択の考え方はShopifyのネイティブ回帰から考えるアプリ開発の見積もりで扱っています。
確認した範囲
2026年10月26日に、Apple Developerのニュース「Prepare and submit your apps for iPhone Duo」（2026年10月5日）、「Build for iPhone Duo with new resources」（9月18日）、iPhone Duoの案内のページと準備のページ（Three steps to make your app shine on iPhone Duo）、App Store Connectのヘルプ「Screenshot specifications」を確認し、公開前の10月27日に同じ資料とAppleのNewsroom（10月23日の発売の記事）で内容を確かめ直しました（資料調査）。grepの検索は、編集部の検証環境（Linux）とmacOS 26.5.1で、検証用に作ったSwiftのファイルに対して実行しました（実機検証）。iPhone Duoの実機、Xcode 27.1、シミュレーター、Xcodeのスキルは試しておらず、実在のアプリの画面も確認していません。
業務アプリの新しい端末への対応や、保守の進め方の見直しは、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Prepare and submit your apps for iPhone Duo（Apple Developer、2026-10-05）
- Build for iPhone Duo with new resources（Apple Developer、2026-09-18）
- Three steps to make your app shine on iPhone Duo（Apple Developer）
- Screenshot specifications（App Store Connect Help）
- iPhone Duo arrives at Apple Store locations worldwide（Apple Newsroom、2026-10-23）
