機能: iPad の分割幅と文字サイズの軸を足す（2.1.0） - #2
Merged
Merged
Conversation
iPadOS 26 で Split View / Slide Over が廃止され、ウィンドウが自由リサイズになった。
HIG は画面の 1/2・1/3・1/4 の各幅で検証せよと書いているが、この装置には全画面の
iPad しか無かったので、狭いウィンドウでの崩れが撮れなかった。
`SnapshotDevice` に `iPadPro11Half`（597×834）と `iPadPro11Third`（398×834）を足す。
幅は横向き（1194pt）を基準に取る —— 縦向きの 1/3 は 278pt で、iPadOS が許す
ウィンドウの最小幅を下回り、実際には作れない面を撮ることになる。
あわせて文字サイズの軸（`SnapshotDynamicType`）を足す。タイポグラフィが
Dynamic Type に追随するようになると、大きい文字での崩れが初めて撮れるようになる。
SwiftUI の環境だけでなく `preferredContentSizeCategory` trait にも効かせる ——
環境だけだと、UIKit が寸法を決める部分（ナビゲーションバー・リスト行の最小高）が
既定サイズのまま残り、実機と違う絵になる。
既存の参照画像を守るために 2 つ手当てした:
- 既定の端末を `SnapshotDevice.allCases` から `standardDevices`（従来の 3 台）に変更。
allCases のままだと、端末を足すたびに全スイートの枚数が黙って増え、
参照画像の無い面が失敗として現れる
- 既定の文字サイズではファイル名を変えない。アクセシビリティサイズのときだけ
`_{dynamicType}` を付ける
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJezxiamqVBJw6eAm2qcxH
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
なぜ
iPadOS 26 で Split View / Slide Over が廃止され、ウィンドウが自由リサイズになった。HIG は画面の 1/2・1/3・1/4 の各幅で検証せよと書いている。この装置には全画面の iPad しか無かったので、狭いウィンドウでの崩れが撮れなかった。
あわせて、タイポグラフィが Dynamic Type に追随するデザインシステムが出てきたので、大きい文字での崩れを撮れるようにする。行の高さ・アイコンとの垂直中心・省略の入り方はここで壊れる。
何を
SnapshotDeviceに iPad のウィンドウ幅を 2 つ.iPadPro11Half.iPadPro11Third幅は横向き（1194pt）を基準に取る。縦向きの 1/3 は 278pt で、iPadOS が許すウィンドウの最小幅を下回り、実際には作れない面を撮ることになるため。
どちらも size class は compact に落ちる。つまりここに写るのは iPad なのに iPhone のレイアウト分岐で描かれた姿で、
readableContentGuide相当の幅制限や regular 前提の 2 カラムは効かない。文字サイズの軸
SnapshotDynamicType.standard（.large）と.accessibility3。SnapshotConfiguration.dynamicTypesで指定する。最大（
.accessibility5）ではなく.accessibility3を検査点にしたのは、最大は何をしても崩れるので回帰の判別に使えないから。SwiftUI の
\.dynamicTypeSize環境とViewImageConfigのpreferredContentSizeCategorytrait の両方に効かせる。環境だけだと、UIKit が寸法を決める部分（ナビゲーションバー・リスト行の最小高）が既定サイズのまま残り、実機と違う絵が撮れる。既存の参照画像を壊さないための手当て
2 つある。どちらも意図的。
SnapshotDevice.allCasesからstandardDevices（従来の 3 台）に変えた。allCasesのままだと、端末を 1 つ足すたびに既存の全スイートが撮る枚数が黙って増え、参照画像の無い面が失敗として現れる。分割幅は、撮ると決めたスイートだけが明示的に足す{state}.{theme}_{locale}.png）。アクセシビリティサイズのときだけ_{dynamicType}が付く結果として 2.0 系で記録した参照画像はそのまま使える。 実際、統合テストの既存 3 スイートで変わったのは manifest のタイムスタンプ 1 行ずつだけ。
確かめたこと
swift build（macOS ホスト）xcodebuild build -destination 'generic/platform=iOS Simulator'xcodebuild test -only-testing:VisualTestingIntegrationTests→ 5 tests / 4 suites 全 greenAdaptiveSample/iPadPro11Half/splitWidths.light_en.pngAdaptiveSample/iPadPro11Third/splitWidths.light_en.pngAdaptiveSample/iPhoneSE/dynamicType.light_en.png（既定サイズ・接尾辞なし）AdaptiveSample/iPhoneSE/dynamicType.light_en_accessibility3.png見ていないこと
.iPhoneSEの宣言が @2x でも @3x で記録される）。これは 2.0 系からの既存の挙動で、このブランチでは触っていないタグ
打っていない。 リリースは別途。