October 29 diagnostic update: we now have matched iPad failure-state hierarchies and screenshots. The earlier XCTest exports contained a main-screen hierarchy captured BEFORE opening the picker. To close that gap, a diagnostic harness now records the hierarchy and screenshot inside the audit issue handler. The three targeted iPad cases reproduce in that matched modal state: landscape normal fails Element Detection; portrait/landscape maximum Dynamic Type fail Contrast. All original assertions and seven audit categories remain intact; the handler returns false. XCUIAccessibilityAuditIssue.element is still nil. Test details, activity exports and matched snapshots expose neither the failed node/bounds nor its sampled colors. We have not identified the exact landscape detection target or the maximum-text contrast targets. Retained evidence for context: The data-free SwiftUI reproduction in the original post passes main-screen Element Detection with the sheet closed and fails with it presented; it uses no app modules or persistence. The portrait Inspector report highlights background Nutrition, Vegetables, Dairy and Grains text behind/outside the sheet. Actual iPad Simulator VoiceOver forward/backward modal traversal passes without reaching those background labels. This is not physical-device or full accessibility acceptance. The iPhone scrolled-state report gives #252526 against #000000, 1.37:1, while XCTest places the count label wholly above the visible results viewport. That is the tool-reported sample, not a verified visible glyph/background pair. Unchanged .95 passes Banana visibility and all picker-control steps before reproducing that contrast failure. Zero visible height occurred in a rejected lazy-stack trial, which was reverted. Debug and Release builds pass. All five original gates remain unresolved: two iPad normal Element Detection cases, two iPad maximum-text Contrast cases, and the separate scrolled iPhone Contrast case. No warning is filtered or waived. Given these matched captures, could Apple clarify: Is Element Detection expected to evaluate background text behind a presented SwiftUI sheet? What supported semantics establish the modal accessibility boundary? When issue.element is nil, which supported diagnostic/export identifies the actual sampled node, bounds and foreground/background colors? How should offscreen or clipped text contrast findings be distinguished from visible contrast defects? What independent VoiceOver/manual evidence should accompany a minimal reproduction when modal focus passes but the audit fails? Original reports, matched screenshots and hierarchies are retained locally. No attachments or private data are included here. We are seeking a diagnosis, not a waiver or a claim that the warnings are harmless.

Yes, that is correct, with one distinction: we retain current and later source snapshots, but cannot authenticate them as the exact source used for those older installed development builds. We have not located the original signed IPA packages or Xcode archives for those installations. The original apps remain installed and have not been updated or uninstalled. We do have current development source and a separately built, signed candidate whose entitlements and provisioning profile we can inspect. We also retain exported app-data containers and backup evidence, but are not treating those as proof of the older binaries’ signed entitlements. Separate disposable QA installations do not establish continuity for the originals. Given that situation, is there an Apple-supported way to establish the installed originals’ effective application-identifier/App ID prefix and Keychain access groups, including default-group ordering, without replacing the apps or extracting Keychain values? If no supported read-only method exists, what minimal controlled diagnostic would you recommend to qualify a same-bundle-identifier update while preserving the original installation and its Keychain access?