Objective‑C UIView ↔ SwiftUI UIViewRepresentable: Propagating accessibilityLabel

Short answer

Set the label (and traits) in updateUIView, not only in init or makeUIView. SwiftUI may recreate or reuse the wrapped view and discard accessibility state configured at creation time, so the only reliable point to propagate values is the update pass. Do not add SwiftUI .accessibilityLabel() modifiers to the representable — that creates a second, competing accessibility element.

Minimal implementation

struct ObjCViewWrapper: UIViewRepresentable {
    @Binding var label: String

    func makeUIView(context: Context) -> MyObjCView {
        let view = MyObjCView()
        view.accessibilityDelegate = context.coordinator // if label can change internally
        return view
    }

    func updateUIView(_ uiView: MyObjCView, context: Context) {
        uiView.accessibilityLabel = label
        // Traits: copy explicitly if the ObjC view manages them
        // uiView.accessibilityTraits = uiView.objcManagedTraits
    }

    func makeCoordinator() -> Coordinator { Coordinator(self) }
}

Copying accessibilityLabel and accessibilityTraits in updateUIView is the minimal guarantee that VoiceOver sees current values, because UIKit reads them from the view at focus time.

Traits synchronization

There is no automatic mirroring of traits into SwiftUI, and you generally should not try to route them through SwiftUI modifiers — .accessibilityAddTraits() on the representable wraps the view in a separate accessibility element, causing duplicate or conflicting announcements. Keep ownership of accessibility on the UIView itself. If the Objective-C view is a UIControl subclass, its built-in traits (e.g. button) are already exposed; copying accessibilityTraits in updateUIView preserves whatever the view sets internally.

Labels that change after creation

If the Objective-C view mutates its own label outside SwiftUI's data flow, updateUIView may not be called — especially on iOS 17+, where update passes can be skipped when inputs appear unchanged. The reliable pattern is:

1. Expose a delegate or closure on the Objective-C view that fires when its label changes.
2. In the Coordinator, write the new value into a @Binding/@State.
3. That state change forces an updateUIView pass, which re-assigns the label.

As a fallback, calling setNeedsAccessibilityUpdate() on the view nudges the accessibility system to re-query, but routing through state is the deterministic option.

Notifications

No forwarding layer is needed for announcements. If the Objective-C view posts UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, ...) on itself, the system speaks it because the view is already in the accessibility hierarchy. UIAccessibilityLayoutChangedNotification also works, though focus behavior depends on the view being the intended focus target.

Verification

• Run with VoiceOver enabled and confirm the label is spoken exactly once, as set on the Objective-C view.
• In Xcode's Accessibility Inspector, verify exactly one accessibility element exists for the wrapper and that label/traits match the UIKit view.
• Trigger a dynamic label change and confirm the new value is announced without recreating the SwiftUI view; test on both iOS 16 and 17+ since updateUIView call frequency differs.

Assumes iOS 16/17+ and a single wrapped view. If your Objective-C view builds a custom UIAccessibilityElement tree internally rather than being directly accessible, the propagation strategy changes — that detail is worth confirming before applying the above.