Repository navigation
SwiftUI.Tab accessibilityIdentifier is not surfaced on native tab targets #442
Description
Summary
XcodeBuildMCP v2.6.1 fixed the important tab automation issue: native UITabBar items are now discoverable and tappable through snapshot-ui. I verified this with XcodeBuildMCP 2.6.2.
There may still be a smaller SwiftUI identifier propagation issue: an .accessibilityIdentifier(...) applied to a SwiftUI.Tab(...) does not appear on the native tab target emitted by snapshot-ui.
This is not blocking automation, because agents can target tabs by role=tab plus visible label. I am filing this as a maybe-bug / enhancement request to clarify whether the identifier can be surfaced or whether this is expected SwiftUI/UIKit behavior.
Example SwiftUI shape
TabView(selection: $selectedTab) {
SwiftUI.Tab("Wheels", systemImage: "arrow.trianglehead.2.clockwise", value: Tab.wheels) {
NavigationStack {
WheelsView()
}
.accessibilityIdentifier("screen_wheels")
}
.accessibilityLabel("Wheels")
.accessibilityIdentifier("tab_wheels")
}Observed snapshot-ui behavior
The native tab item is discovered and tappable, but the identifier field is empty:
eNN|tap|tab|Dashboard|1|
eNN|tap|tab|Wheels|0|
eNN|tap|tab|Positions|0|
eNN|tap|tab|Spec Trades|0|
eNN|tap|tab|Trade Log|0|
Tapping the Wheels tab element reference works and changes to the Wheels screen.
Expected or requested behavior
If SwiftUI forwards the identifier in a way XcodeBuildMCP can observe, it would be useful for snapshot-ui to surface tab_wheels on the native tab target.
If SwiftUI does not forward that identifier to the underlying UITabBarItem, documentation confirming that tab automation should use role + label would also resolve the ambiguity.
Environment
- XcodeBuildMCP: 2.6.2
- Relevant fix already present: v2.6.1 tab bar item discovery fix
- App UI: SwiftUI
TabViewusingSwiftUI.Tab
Activity
vsolano9 commentedon Jul 1, 2026
Reproduced this on an iPhone 17 Pro simulator with a minimal
SwiftUI.Tabapp andaxe describe-ui. The tab node comes through asrole_description: tab/ subroleAXTabButtonwithAXLabelset butAXUniqueId: null, and thetab_*string is absent from the entire accessibility tree. An.accessibilityIdentifierapplied to the tab's content (e.g.screen_wheels) does propagate normally.So the identifier applied to a
SwiftUI.Tabis not forwarded to the underlying tab bar item's accessibility element; there is nothing forsnapshot-uito surface.normalizeNodealready readsAXUniqueId/AXIdentifierwhen present. Tab automation byrole=tab+ visible label works and is the reliable approach.Opened #456 with regression coverage for both cases (no identifier surfaced when the platform exposes none; identifier surfaced when it does). Happy to add a website docs note if useful.
test(ui-automation): cover SwiftUI tab identifier surfacing (#442) (#456
cameroncooke commentedon Jul 16, 2026
Closing with the reproduced platform evidence from #456. On a native
SwiftUI.Tab, AXe reports the tab node with its label/role butAXUniqueIdis null, and the requestedtab_*identifier is absent from the complete accessibility tree. XcodeBuildMCP already readsAXUniqueId/AXIdentifierwhenever the platform supplies one, so there is no identifier available for it to surface or safely synthesize. PR #456 added regression coverage for both cases. Native tabs should be targeted byrole=tabplus their visible label.