ci: run the iOS UI suite on iPad as well as iPhone - #5
Merged
Merged
Conversation
The app ships iPad (TARGETED_DEVICE_FAMILY "1,2") and the UI it presents there is structurally different: a NavigationSplitView with a sidebar rather than a compact NavigationStack with a navigationBarDrawer search field. The UI suite branches on the idiom, but only the iPhone half had ever run -- CI resolved a single iPhone simulator for every iOS step, so the iPad paths were dead code in practice. Adds ipad to the existing matrix. fail-fast is already false, so one device failing still reports the other. Unit tests stay pinned to the iphone leg; they are pure logic and device-independent. No other change was needed: Scripts/resolve-ios-simulator.sh already takes a device family, and the macos-26 image carries iPad models on the iOS 26.5 runtime the resolver selects. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adding the ipad leg to CI (previous commit) failed 3 of 12 UI tests. All three were the suite's helpers assuming an iPhone-shaped NavigationStack; NavigationSplitView needed different queries, not different behavior. Root-caused each by dumping the real accessibility tree rather than guessing: - revealSearchField: .searchable(placement: .sidebar) puts the field above the sidebar's first row, off-screen above the viewport. A full-screen swipeDown() (the iPhone path) hits the detail pane and scrolls nothing. Falls back to swiping the "Sidebar" collection view directly. - returnToList: with two navigation bars on screen (sidebar + detail pane), navigationBars.buttons.firstMatch resolved to the DETAIL pane's first button -- "New Note" -- so this was silently creating a note instead of navigating. iPad has nothing to pop; the list is always visible. Guarded on a new isSplitViewLayout(in:) check. - Two membership/deletion assertions: a note's title renders in both the sidebar row and the detail pane on iPad, so app.staticTexts[title] is ambiguous, and a stale detail pane can defeat a "no longer in the list" check. Added noteList(in:) to scope those queries to the actual list. - Permanent-delete confirmation: both the detail pane and the confirmation dialog have a "Delete Now" button. Picking the last app-wide match assumed the dialog sorts after the pane, which does not hold on iPad, where the confirmation is a popover -- the pane's own button was tapped, the dialog was never confirmed, and the note silently survived. Added confirmPermanentDelete(in:), scoped to the sheet/alert container. Verified: 12/12 pass on iPad, 12/12 on iPhone -- including on a fresh, disposable simulator, to rule out interference from other sessions sharing this machine's simulators. Zero syntax errors from a standalone parse of the changed file. Also removed four identical, untracked duplicate files (iCloud sync artifacts: Localizable 2.xcstrings, ScreenshotDemoContent 2.swift, LocalizationTests 2.swift, verify-localization 2.sh) that broke local compilation with "invalid redeclaration" -- unrelated to this branch, but blocked reproducing the CI failure locally. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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
1 participant
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.
Adds
ipadto the iOS matrix, now that the iPad-capable UI suite has landed ondevelop.Why this was blocked until now
The app ships iPad (
TARGETED_DEVICE_FAMILY "1,2") and presents structurally different UI there — aNavigationSplitViewwith a sidebar, rather than a compactNavigationStackwith anavigationBarDrawersearch field. The UI suite branches on the idiom, but only the iPhone half had ever run anywhere: CI resolved a single iPhone simulator for every iOS step, so the iPad paths were dead code in practice.Why no other change was needed
Scripts/resolve-ios-simulator.shalready takes a device family.macos-26image carries iPad models (Pro, Air, mini, A16) on the iOS 26.5 runtime the resolver selects — verified against theactions/runner-imagesmanifest.fail-fast: falsewas already set, so one device failing still reports the other.This run is the first time the iPad UI paths execute anywhere.
🤖 Generated with Claude Code