Found: WP5 gate session, 2026-09-16, setting up the new 4-leg simulator matrix (docs/testing.md "Which simulator OS — a policy, not a pinned number") — the 27.0 "newest available" legs.
Freshly created iPad Pro 11-inch (M4) and iPhone 13 mini simulators on the iOS 27.0 runtime (xcrun simctl create) show a SpringBoard-level "Bei Apple Account anmelden" (Sign in to Apple Account) modal over the app's onboarding screen, immediately on first launch after boot. It blocks all XCUITest automation (the whole run just hangs — no test progress, no timeout from xcodebuild itself).
Tried:
- Tapping Abbrechen (Cancel) manually on the device — the dialog reappears immediately (Jan, 2026-09-16: "abbrechen hilft nicht. meldung kommt sofort wieder").
xcrun simctl shutdown + xcrun simctl erase + reboot — dialog reproduces again on the freshly erased device too.
Not reproduced on the existing 17.5/18.6/26.5 simulators (all created earlier, presumably already past whatever first-boot account-probe state triggers this on a truly fresh device).
Hypothesis, not verified: something the app does at launch — PhotoAlbumPickerView's iCloud-album path, or CompanionSync's NSUbiquitousKeyValueStore/CloudKit account-status check in OwnFrameApp.swift (even though CompanionSync is meant to no-op without the iCloud/KVS entitlement, see #66) — triggers an account-status probe that a truly fresh iOS 27.0 simulator answers by nagging for sign-in, repeatedly. Could also be OS-level and unrelated to our code. Needs someone to bisect with a stripped-down app or Apple's own sample app on the same fresh 27.0 sim to tell which it is.
Impact: the WP5 gate session ran on the 17.5 legs + host packages only; the 27.0 ("newest available") legs of the new gate policy are blocked until this is root-caused. docs/testing.md notes the gap explicitly rather than silently claiming all 4 legs ran.
Found: WP5 gate session, 2026-09-16, setting up the new 4-leg simulator matrix (
docs/testing.md"Which simulator OS — a policy, not a pinned number") — the 27.0 "newest available" legs.Freshly created
iPad Pro 11-inch (M4)andiPhone 13 minisimulators on the iOS 27.0 runtime (xcrun simctl create) show a SpringBoard-level "Bei Apple Account anmelden" (Sign in to Apple Account) modal over the app's onboarding screen, immediately on first launch after boot. It blocks all XCUITest automation (the whole run just hangs — no test progress, no timeout from xcodebuild itself).Tried:
xcrun simctl shutdown+xcrun simctl erase+ reboot — dialog reproduces again on the freshly erased device too.Not reproduced on the existing 17.5/18.6/26.5 simulators (all created earlier, presumably already past whatever first-boot account-probe state triggers this on a truly fresh device).
Hypothesis, not verified: something the app does at launch —
PhotoAlbumPickerView's iCloud-album path, orCompanionSync'sNSUbiquitousKeyValueStore/CloudKit account-status check inOwnFrameApp.swift(even though CompanionSync is meant to no-op without the iCloud/KVS entitlement, see #66) — triggers an account-status probe that a truly fresh iOS 27.0 simulator answers by nagging for sign-in, repeatedly. Could also be OS-level and unrelated to our code. Needs someone to bisect with a stripped-down app or Apple's own sample app on the same fresh 27.0 sim to tell which it is.Impact: the WP5 gate session ran on the 17.5 legs + host packages only; the 27.0 ("newest available") legs of the new gate policy are blocked until this is root-caused.
docs/testing.mdnotes the gap explicitly rather than silently claiming all 4 legs ran.