ui: use cable.connector SF Symbol for USB toolbar item

[tan9]

Summary

The USB toolbar item was the only icon in the VM session window using a bundled bitmap (Toolbar USB.imageset) instead of an SF Symbol. Its stroke weight and overall sizing visibly differed from the surrounding system symbols (cursorarrow.rays, arrow.up.left.and.arrow.down.right, opticaldisc, folder.badge.person.crop, rectangle.on.rectangle, …). The mismatch is especially noticeable on the floating capsule toolbar introduced in macOS 26 (Tahoe), where the lighter USB stroke sticks out next to its neighbours.

*(Before / After comparison)*

Changes

• Platform/macOS/Display/VMDisplayWindowController.swift — override usbToolbarItem.image with NSImage(systemSymbolName: "cable.connector", …) on macOS 12+ inside a new setupToolbarIcons() helper called from windowDidLoad. Older macOS releases (macOS 11.3) keep using the bundled template image from the nib.
• Platform/iOS/VMToolbarUSBMenuView.swift — use Label("USB", systemImage: "cable.connector") on iOS 15 / macOS 12 / visionOS 1 or later. Older releases (iOS 14) still fall back to Label("USB", image: "Toolbar USB").

cable.connector was introduced in SF Symbols 3, so the symbol path covers every deployment target down to the documented minimum and the bundled Toolbar USB PNG only renders on iOS 14 / macOS 11.3.

Testing

Testing: Tested by a human on MacBook Pro M1 Max, macOS 26.5 (Tahoe). The author acknowledges that this change has been tested and/or reviewed by a human in accordance with UTM's AI contribution guidelines.

Verified

• USB toolbar item now matches the stroke weight and visual size of the adjacent SF Symbols (cursorarrow.rays, arrow.up.left.and.arrow.down.right, opticaldisc, folder.badge.person.crop, rectangle.on.rectangle) in the floating capsule toolbar on macOS 26 Tahoe — see the Before / After comparison above.

Not verified (out of scope for this change)

• Live USB device connect / disconnect through the menu — the local development build is unsigned and lacks the Hypervisor / SPICE entitlements required to actually start a guest, so the VM session itself could not be exercised. The change only swaps the image on the existing usbToolbarItem / SwiftUI Label; no IBAction, target, menu, or enterSuspended wiring is touched, so functional behaviour should be unaffected.
• macOS 11.3 host — I do not have that system available; the fallback path keeps the existing Toolbar USB template image from the nib, so behaviour on that release should be identical to before.
• iOS / iPadOS / visionOS — not built locally. The SwiftUI change is gated by #available(iOS 15, macOS 12, visionOS 1, *) and falls back to the same bundled image on iOS 14.

Notes

Code is AI-assisted. The commit carries Assisted-by: Claude:claude-opus-4-7 per UTM's attribution policy.

I have read the AI contribution guidelines and have followed them to the best of my ability.

[osy]

macOS 14? Either that means iOS wrong (iOS 17 is the aligned release) or macOS is wrong. Can you check by testing?

[tan9]

You're right, thanks for catching this — both versions were wrong.

cable.connector is actually an SF Symbols 3 symbol (iOS 15 / macOS 12 / tvOS 15 / watchOS 8 / visionOS 1), not SF Symbols 5 as I had mistakenly assumed. The metadata in SFSafeSymbols (which is autogenerated from Apple's SF Symbols catalog) lists it under the @available(iOS 15.0, macOS 12.0, tvOS 15.0, watchOS 8.0, visionOS 1.0, *) 3.0 extension:

@available(iOS 15.0, macOS 12.0, tvOS 15.0, watchOS 8.0, visionOS 1.0, *)
public extension SFSymbol {
    ...
    static var cableConnector: SFSymbol { .init(rawValue: "cable.connector") }

I've tightened the checks to:

• Platform/macOS/Display/VMDisplayWindowController.swift: #available(macOS 12, *)
• Platform/iOS/VMToolbarUSBMenuView.swift: #available(iOS 15, macOS 12, visionOS 1, *)

so the SF Symbol path now covers every deployment target down to the documented minimum and the bundled Toolbar USB PNG only renders on iOS 14 / macOS 11.3. Force-pushed to the same branch.

[osy]

Hi, we've recently updated CONTRIBUTING.md specifically changed how the AI attribution should be handled. Please read that and ensure your commit adheres to the new guidelines. Also please use the /utm-review and /utm-submit skills to update the PR if you are using an AI coding tool that supports skills.

[tan9]

Thanks for the heads-up. I've rebased onto main to pick up the new CONTRIBUTING.md / AGENTS.md and the /utm-review + /utm-submit workflows, run them through, and force-pushed the result. Specifically:

• Commit trailer: dropped Co-authored-by, added Assisted-by: Claude:claude-opus-4-7 per the new attribution policy.
• PR description: replaced the old attestation wording with the new "I have read the AI contribution guidelines and have followed them to the best of my ability." line, added the explicit Testing: acknowledgement, and tightened the SF Symbol availability claims to the corrected iOS 15 / macOS 12 / visionOS 1 range (rolled in with your earlier review comment).

PTAL when you have a moment.