2026年10月25日時点では、iOS 27.1以降にUIKitの内容が端へ寄った場合、まず子ビューがUIViewの既定layoutMarginsに依存していないか確認してください。必要ならdirectionalLayoutMarginsを明示するか、親ビューの余白を継承させ、対象システムのシミュレーターで再確認します。すべての画面が自動的に端へ寄るわけではなく、安全領域の変更と決めつけるのも避けてください。AppleのiOS 27.2 RCリリースノートでは、iOS 27.1以降のUIViewの既定レイアウト余白がゼロであることが確認されています。

対象読者
UIKitの自動レイアウトを保守し、OS更新後に間隔が変わった開発者向けです。
iOS 27.1以降の互換性確認で、ルートビューと子ビューの余白の違いを調べたい人にも役立ちます。
リモートMacでXcodeやシミュレーターを使う小規模チームにも向けて、再現条件の記録方法を説明します。

※最終更新：2026年10月25日。仕様はAppleのiOS 27.2 RCリリースノート、UIKitの各プロパティ資料、およびXcodeのシステム要件で確認しています。正式版の公開や資料の更新があれば、適用範囲を再確認してください。

01

Xcode 27.2 RCで起きたUIKitの余白ずれは、まず既定値から切り分けます

iOS 27.1以降、UIViewの既定layoutMarginsはゼロです。ただし、これは「すべてのUIKit画面が端まで詰まる」という意味ではありません。UIViewControllerのルートビューには、表示状況に応じたsystemMinimumLayoutMarginsが関わります。子ビューが独自の余白を設定しているか、親から余白を引き継ぐかによっても見え方は変わります。ルートビューの仕様はAppleのsystemMinimumLayoutMargins資料で確認できます。

iOS 27.1でUIViewの既定余白がゼロになったのはなぜですか？
Appleが公開している説明から確認できるのは、iOS 27.1以降のUIViewの既定レイアウト余白がゼロになったことです。変更の理由を推測して修正方針を決めるより、影響を受けた画面で余白を参照しているビューと制約を特定してください。レイアウト余白の使い方を確認し、制約の参照先を見直すのも有効です。

例えば、一覧セルのラベルが親ビューの余白を前提にしている一方、子ビュー自身の余白を明示していないとします。親ビューは従来どおりに見えても、子ビューの制約だけが端へ寄る可能性があります。これは切り分けのための例であり、実際に起きるかどうかはビュー階層と制約によります。

02

ルートビューと子ビューを分けて見る

UIViewControllerのルートビューと、一般的な子UIViewでは、余白の設定元が同じとは限りません。制約がlayoutMarginsGuideを使っていても、どのビューのガイドを参照しているかによって位置は異なります。ビュー階層を開き、制約の所有元と参照先を確認してください。

確認対象 見るべき設定 判断と次の操作
UIViewControllerのルートビュー systemMinimumLayoutMarginsと画面の表示状況 ルートビューの余白を取得し、子ビュー側の値と分けて記録します。
一般的な子UIView layoutMargins、directionalLayoutMargins 既定値を前提にせず、画面設計に必要な余白を明示します。
親から子への継承 preservesSuperviewLayoutMargins 親の余白に追従させる設計か確認してから有効にします。
セーフエリアとの関係 insetsLayoutMarginsFromSafeAreaと制約 セーフエリアとレイアウト余白を別々に点検します。

ルートビューのシステム最小余白は、一般的な子UIViewの既定余白と同一ではありません。ルートビューの値を、すべての階層にそのまま当てはめないようにします。

親の余白を引き継ぐ設計か判断します

preservesSuperviewLayoutMarginsは、子ビューが親ビューのレイアウト余白を考慮するかを制御します。既定値に依存している箇所は、Appleのプロパティ資料を参照して、実際の設定と期待する挙動を照合してください。親に余白があるからといって、すべての子ビューが自動的に同じ余白を使うとは限りません。

子ビューにUIViewControllerのルートビューの余白を引き継がせるには？
親の余白にそろえる必要がある子ビューで、preservesSuperviewLayoutMarginsを有効にする方法があります。親子関係を確認し、その子ビューが親の余白に従う設計かを先に決めてください。階層の途中に別のコンテナがある場合は、意図しない余白まで受け継がないか、最小の画面で検証します。

03

第一段階：最小画面で原因を再現します

Xcode 27.2 RCでUIKitの内容が端に寄る問題を再現するには？
問題が起きる画面から必要なビューと制約だけを残し、対象のOSランタイムで同じ表示になるか確認します。Xcodeの使用条件はAppleのシステム要件と照合し、シミュレーターと実機の確認を混同しないでください。

次の順に進めると、余白の変更と別のレイアウト変更を分けやすくなります。

  • 再現条件を固定します。 OSのバージョン、ビルドに使ったXcode、画面、操作、端に寄る部品を記録します。
  • 新旧の表示を比較します。 同じ画面を比較し、変化したビューと制約を特定します。別のレイアウト変更も同時に起きていないか確認します。
  • 制約の参照先を調べます。 layoutMarginsGuide、safeAreaLayoutGuide、ビューの端のどれに制約しているかを確認します。
  • 余白を読み取ります。 ルートビューと問題の子ビューについて、layoutMargins、directionalLayoutMargins、継承設定をそれぞれ調べます。
  • 最小の修正を加えます。 子ビューに必要な余白を設定するか、設計に合う場合だけ親の余白を継承させます。
  • ログと階層を再確認します。 制約の競合や、後から余白を上書きするコードがないかを調べます。
  • 対象ランタイムで回帰確認します。 修正前後を同じ画面条件で比較し、シミュレーターの結果と実機の確認結果は分けて記録します。Appleのシミュレーターと実機での実行に関する説明も参照してください。

layoutMarginsを設定した後にずれが残る場合は、値をさらに足す前に、制約がその余白を参照しているか確認してください。後続コードによる再設定や、セーフエリアとの混同も原因候補です。

04

directionalLayoutMarginsとセーフエリアを別々に検証します

余白を明示する場合は、左右を固定するleft・rightではなく、文字方向に応じて入れ替わるleading・trailingを使うdirectionalLayoutMarginsが候補になります。AppleのdirectionalLayoutMargins資料に沿い、アプリ内のデザイン用定数を使って設定します。

view.directionalLayoutMargins = NSDirectionalEdgeInsets(
    top: DesignMetrics.contentInset,
    leading: DesignMetrics.contentInset,
    bottom: DesignMetrics.contentInset,
    trailing: DesignMetrics.contentInset
)

ここで使うDesignMetrics.contentInsetは、アプリ側で定義した値を表す例です。Appleが推奨する固定値を示すものではありません。既存のデザイントークンや画面仕様に合わせて決め、設定が別の処理で上書きされていないかも検索してください。

directionalLayoutMarginsを設定した後、RTLレイアウトはどう確認しますか？
アラビア語などの右から左へ読む設定で画面を表示し、余白がleading・trailingに従って左右反転するか確認します。固定方向の制約が残っていると、余白だけが反転して部品の配置が反転しないことがあります。対称な画面だけで済ませず、左右に意味のある操作部品がある画面も見ます。

セーフエリアは、ノッチやシステム領域を避けるための領域です。レイアウト余白とは別の仕組みですが、insetsLayoutMarginsFromSafeAreaの設定によって相互に関係します。Appleのセーフエリアとレイアウト余白の説明を確認し、セーフエリア用ガイドを余白用ガイドの代わりとして使っていないかを点検してください。

05

症状に応じて修正方法を選びます

次の条件分岐で、修正範囲を必要な部分に絞れます。

  • 子ビューが独自の余白を持つべきなら、そのビューのdirectionalLayoutMarginsを明示します。親の設定変更が別の画面へ波及するのを避けやすくなります。
  • 子ビューが常に親の余白にそろう設計なら、preservesSuperviewLayoutMarginsを検討します。親から子までの階層を確認し、意図しない継承があれば個別に設定します。
  • ルートビューとセーフエリアの位置関係が問題なら、systemMinimumLayoutMarginsとsafeAreaLayoutGuideを分けて調べます。UIViewの既定値だけを変更しても解決しない場合があります。
  • 制約が余白ガイドを使っていないなら、まず制約の参照先を設計意図に合わせます。ビューを作り直したり、画面全体に一律の値を適用したりするのは、その後でも遅くありません。
  • SwiftUIとの境界だけで発生するなら、ホストするUIKitビューとSwiftUIコンテナを切り分けて再現します。SwiftUIのpaddingや安全領域の修飾子を、UIViewの余白設定の代用品として扱わないでください。

SwiftUIとUIKitを混在させた画面では、コンテナ側の余白、ホストされたビューの制約、子UIView自身の余白が別々に働く場合があります。純粋なUIKit画面では再現せず、混在画面だけで起きるなら、最小構成の比較で責任範囲を特定してください。

06

修正を止める条件と回帰記録を決めます

対象システムの画面で、問題のビューが設計どおりの位置にあり、制約競合がなく、RTL表示でも意図しない左右ずれがないことを確認できたら、余白の追加を止めます。余白の数値を調整し続けるより、再現条件と修正したプロパティ、制約の参照先を記録するほうが、後のOS更新で比較しやすくなります。

シミュレーターでの表示確認は、そのシミュレーター環境での確認です。実機の表示や操作まで保証するものではありません。実機での確認が必要な画面では、別途その確認を記録してください。

07

作業環境は再現性を基準に選びます

XcodeやOSランタイムの組み合わせを変えて繰り返し確認するなら、作業環境の選び方も切り分け精度に関わります。ローカルMacなら実機接続や周辺機器を扱いやすい一方、別の検証環境を用意するにはハードウェア費用と保守が必要です。共有環境では、誰がツールチェーンやシミュレーターを変更したか追いにくくなることもあります。

必要な確認が短期間で、手元に検証用Macがないなら、リモートMacを使う選択肢があります。自分の手元にあるMacで長期的に安定した高負荷処理を続けたい場合や、直接接続する物理機器が不可欠な場合は、購入またはローカル環境のほうが適しています。環境の違いを見比べるなら、VpsMeshのMac環境を確認し、購入する場合の条件はMac miniの案内と合わせて検討できます。

ローカルの開発環境だけで検証すると、ツールチェーンの更新が普段の作業へ影響したり、共有Macでは変更履歴を追いにくくなったりします。異なるシミュレーターで繰り返し回帰確認する必要があるなら、VpsMeshのリモートMacを独立した検証環境として使う方法もあります。実際の接続方法や提供内容を確認し、プロジェクトの期間と必要な周辺機器に合う場合に選んでください。