Found: 2026-09-15, WP5 release gate, first run on real hardware since 2026-07-28. Related: #50 (iOS 27 synthesized-tap failures), #54 (StoreKit on 26.x simulators).
FramePhone (iPhone 13 mini), iOS 27.0 GA (24A435)
- App-hosted
OwnFrameTests: 109 passed / 0 failed / 6 skipped (the 6 are the source-tree guard suites, now simulator-only — they read the repo via #filePath, which a device cannot reach).
OwnFrameUITests: 93 passed / 5 failed / 69 skipped (skips = the env-gated capture, rig and live-smoke suites).
New: three protected-link tests fail (not in #50's list)
SharedLinkPasswordUITests/testOnboardingProtectedLinkPromptsWrongThenCorrect — a wrong password should surface a distinct errorSharedLinkPasswordUITests/testSettingsProtectedLinkWrongPasswordErrorsAndPersistsNothing — sameSharedLinkOnboardingUITests/testProtectedSharedLinkPromptsOnceThenReachesSlideshow — the Immich link should route to the running slideshow
The last frame of each screen recording shows the same state: the password is typed into the field, the keyboard is up, and the Continue row was never activated — the sheet is still open, so neither the error nor the slideshow can appear. The tests submit with app.buttons["…password.continue"].tap().
What changed since these passed on FramePhone (27.0 beta, 2026-07-28):
- Our code: the Continue buttons in
SharedLinkSetupView.swift / SharedLinkAddForm.swift are unchanged since July; the only later commit touching either file (73ff5f0) changed copy strings only.
- The OS: 27.0 beta → 27.0 GA (24A435).
All three pass on the iPad Pro 11-inch (M4) simulator, iOS 17.5. Hypothesis, not verified: a synthesized tap on a Form button inside a sheet does not activate while the keyboard is up on 27.0 GA — the same family as #50. To settle: tap via coordinate, or submit via the keyboard's return key, on the device.
Changed: AlbumBrowserUITests/testAlbumBrowserOpensDrillsInAndSelectionReturnsToSlideshow
Fails with Expected failure 'iOS 27: synthesized taps do not activate a NavigationLink in a LazyVGrid in a sheet (#50)' but none recorded — the #50 defect no longer reproduces on 27.0 GA. The expected-failure marker needs to go (or be scoped to the beta).
Known: SlideshowChromeUITests/testChromeInsetsStableAcrossOrientationAndKenBurns
Already listed in #50 as failing on hardware on both 26.5 and 27.0.
iPad Pro 11-inch (M4) simulator, iOS 26.5
StoreKitClientTests/test_askToBuy_deferral_returnsPending_thenApprovalBecomesOwned fails with a bound SKTestSession must report a storefront — issue #54's skip condition assumes an empty one means the session never bound (StoreKitClientTests.swift:114), after which the run stops producing output (13 min, reproduced twice, killed both times). So on 26.5 simulators the suite neither passes nor skips cleanly. StoreKit is 7/7 on FramePhone 27.0. Gate runs on 26.5 currently skip the class.
Found: 2026-09-15, WP5 release gate, first run on real hardware since 2026-07-28. Related: #50 (iOS 27 synthesized-tap failures), #54 (StoreKit on 26.x simulators).
FramePhone (iPhone 13 mini), iOS 27.0 GA (24A435)
OwnFrameTests: 109 passed / 0 failed / 6 skipped (the 6 are the source-tree guard suites, now simulator-only — they read the repo via#filePath, which a device cannot reach).OwnFrameUITests: 93 passed / 5 failed / 69 skipped (skips = the env-gated capture, rig and live-smoke suites).New: three protected-link tests fail (not in #50's list)
SharedLinkPasswordUITests/testOnboardingProtectedLinkPromptsWrongThenCorrect—a wrong password should surface a distinct errorSharedLinkPasswordUITests/testSettingsProtectedLinkWrongPasswordErrorsAndPersistsNothing— sameSharedLinkOnboardingUITests/testProtectedSharedLinkPromptsOnceThenReachesSlideshow—the Immich link should route to the running slideshowThe last frame of each screen recording shows the same state: the password is typed into the field, the keyboard is up, and the Continue row was never activated — the sheet is still open, so neither the error nor the slideshow can appear. The tests submit with
app.buttons["…password.continue"].tap().What changed since these passed on FramePhone (27.0 beta, 2026-07-28):
SharedLinkSetupView.swift/SharedLinkAddForm.swiftare unchanged since July; the only later commit touching either file (73ff5f0) changed copy strings only.All three pass on the iPad Pro 11-inch (M4) simulator, iOS 17.5. Hypothesis, not verified: a synthesized tap on a Form button inside a sheet does not activate while the keyboard is up on 27.0 GA — the same family as #50. To settle: tap via
coordinate, or submit via the keyboard's return key, on the device.Changed:
AlbumBrowserUITests/testAlbumBrowserOpensDrillsInAndSelectionReturnsToSlideshowFails with
Expected failure 'iOS 27: synthesized taps do not activate a NavigationLink in a LazyVGrid in a sheet (#50)' but none recorded— the #50 defect no longer reproduces on 27.0 GA. The expected-failure marker needs to go (or be scoped to the beta).Known:
SlideshowChromeUITests/testChromeInsetsStableAcrossOrientationAndKenBurnsAlready listed in #50 as failing on hardware on both 26.5 and 27.0.
iPad Pro 11-inch (M4) simulator, iOS 26.5
StoreKitClientTests/test_askToBuy_deferral_returnsPending_thenApprovalBecomesOwnedfails witha bound SKTestSession must report a storefront — issue #54's skip condition assumes an empty one means the session never bound(StoreKitClientTests.swift:114), after which the run stops producing output (13 min, reproduced twice, killed both times). So on 26.5 simulators the suite neither passes nor skips cleanly. StoreKit is 7/7 on FramePhone 27.0. Gate runs on 26.5 currently skip the class.