Add SwiftUI support

[daisuke0131]

Summary

• Detect SwiftUI Text / Image / Button through the accessibility elements SwiftUI publishes: new MeasurementTarget abstraction, AccessibilityElementScanner, and overlay integration with cross-framework (UIKit x SwiftUI) distance measurement
• Detect List rows: List inserts a UICollectionView between the hosting view and row content, so the scanner reads accessibility elements from every view in a hosting subtree (rows measure one element per row, matching how List publishes them)
• Block touches on the app while measuring is ON: a transparent shield absorbs app-bound taps, scrolls, and edge swipes, so accidental interaction can't fire actions or trigger a screen transition that would discard the measurement overlay. Only ViewMonitor's own UI receives touches; toggle OFF to interact with the app
• All monitor buttons (UIKit targets and SwiftUI elements) attach to the root view above the shield, in window coordinates. Effectively invisible targets (hidden or alpha 0) get no button
• Add View.viewMonitor() so apps using the SwiftUI lifecycle can start the monitor without a SceneDelegate
• Add ViewMonitor.enableSwiftUIElementDetection(): iOS builds the accessibility tree only while an accessibility client is attached, so without this call SwiftUI detection finds nothing in a normal run. It starts tree construction in-process the same way UI test runners do. Debug builds only — the implementation is compiled out of release builds (no-op returning false, no private-API symbol strings in the binary)
• When SwiftUI content is present but no accessibility elements can be detected, the info panel now shows setup instructions instead of failing silently
• Render InfoView rows with SwiftUI internally (UIKit contract unchanged)
• Add a SwiftUI lifecycle example app (Example/ViewMonitorSwiftUIExample, generated by a Ruby script like the existing example) and build it on CI

Known limitations

• Monitor buttons are fixed at window coordinates and do not follow scrolling; with the input shield, scrolling while measuring is blocked anyway — toggle OFF, scroll, toggle ON to re-scan
• .accessibilityElement(children: .combine) regions and List rows measure as one element; .accessibilityHidden(true) views are not detected; font/background/cornerRadius show None

Notes for reviewers

• Manual testing on device surfaced four significant issues, all fixed here:
  • InfoView's internal UIHostingController fires viewDidAppear when the overlay is shown; the swizzled transition hook mistook that for an app screen transition and reload() tore down the overlay that had just been presented — the toggle appeared to never turn on
  • The previously documented simulator workaround (defaults write com.apple.Accessibility AutomationEnabled 1) does not actually work — the tree stays empty even after a simulator reboot. Replaced by enableSwiftUIElementDetection()
  • List rows were not detected at all, because row elements are published by CellHostingView (not _UIHostingView-prefixed) inside collection view cells
  • With monitor buttons inside their target views, taps on them died under the shield: passing them through requires re-running the hit test through _UIHostingView.hitTest, which is not a pure function — on device it returned the monitor button on the first call and itself on the second for the same point (captured via on-device logging). Buttons now attach above the shield instead, so no touch ever routes through SwiftUI's hit testing
• An earlier version of this branch deleted a unit test against a real UIHostingController accessibility tree because the tree never materialized in the unit-test host. In-process activation unblocks it: SwiftUIElementDetectionTests now verifies Text/Image/Button detection and List row detection against real hosting views rather than fakes
• Earlier launcher fixes retained from the original review round: z-order fix for the launcher vs element buttons, and a launcher retain-cycle fix with a deallocation regression test

Test plan

• 122 tests / 20 suites green; swiftlint --strict 0 violations; both example apps build
• Unit tests cover: injected fake accessibility elements (scanner, inspector, overlay, distance, z-order, deallocation), hosting-subtree scanning incl. dedup and the pure-UIKit guard, real UIHostingController trees end-to-end (VStack content and List rows), the InfoView-triggered teardown regression, the "no elements detected" notice, and the input shield (absorb, button placement above the shield, invisible-target skip, z-order, removal on hide)
• Verified on a clean simulator (no external accessibility client): toggle ON shows measurement buttons over all UIKit and SwiftUI elements in both example apps — including every visible List row — with hit-testing resolving to the shield on empty areas and to measurement buttons over targets
• Verified on device: toggle, UIKit-label measurement, and SwiftUI element measurement (on-device touch logging traced the fix for the shield/hit-test issue)

🤖 Generated with Claude Code