API to get the system pointer’s actual rendered size (respecting Accessibility → Pointer size)?

I'm positioning a tooltip-style panel relative to the mouse pointer and need to avoid overlapping the pointer glyph itself. This works fine at the default pointer size, but breaks once the user sets System Settings → Accessibility → Pointer → Pointer size to something larger than Normal — the pointer is visibly bigger on screen, but my offset doesn't grow to match, so the tooltip overlaps it.

The only cursor-size-related value I've found any API expose is the ratio behind that same setting, read via:

/usr/bin/defaults read com.apple.universalaccess mouseDriverCursorSize

This returns a scale factor (1.0 = Normal, larger toward Large), not a size in points. I'm using it to scale a fixed offset, but that only approximates the real on-screen footprint of the pointer glyph — it doesn't tell me the glyph's actual rendered bounding box, so the tooltip still clips the pointer at larger sizes.

Question: Is there a supported API — AppKit, Accessibility, or otherwise — that returns the system pointer's actual rendered size (bounding box, in points) reflecting the user's Pointer size setting? Or is there a different recommended approach for positioning UI relative to the live pointer without overlapping it, that doesn't depend on knowing that size directly?

Minimal repro (AppKit, Swift Package Manager, no storyboard/xib — ~150 lines):

enum CursorPrefs {
    static func readPointerScale() -> Double {
        let process = Process()
        process.executableURL = URL(fileURLWithPath: "/usr/bin/defaults")
        process.arguments = ["read", "com.apple.universalaccess", "mouseDriverCursorSize"]
        let outputPipe = Pipe()
        process.standardOutput = outputPipe
        process.standardError = Pipe()
        try? process.run()
        process.waitUntilExit()
        let data = outputPipe.fileHandleForReading.readDataToEndOfFile()
        let output = String(data: data, encoding: .utf8)?.trimmingCharacters(in: .whitespacesAndNewlines) ?? ""
        guard let scale = Double(output), scale >= 1.0 else { return 1.0 }
        return scale
    }
}
// A tracking-area view shows a tooltip-style NSPanel near NSEvent.mouseLocation,
// offset by a fixed amount scaled by the value above. At Pointer size = Large,
// the tooltip still overlaps the (visibly bigger) pointer glyph, because the
// value is a ratio, not the glyph's rendered size in points.

Steps to reproduce:

  1. Run the demo app (swift run, or open Package.swift in Xcode and Run).
  2. Open System Settings → Accessibility → Pointer → Pointer size and set it to Large.
  3. Quit and relaunch the demo (it reads the setting once at launch).
  4. Move the mouse over the gray box in the window.
  5. The floating tooltip tracks the pointer but still overlaps the now-larger pointer glyph.

Environment: macOS 14.7.8 (23H730, Xcode 16.2 (16C5032a), Swift 5.9, arm64 (Apple Silicon).

Happy to attach the full repro project as a zip if useful — it's a single main.swift plus an SPM manifest, no external dependencies.

You definitely don't want to call out to a separate process. You can get this value from UserDefaults.standard.persistentDomain(forName: "com.apple.universalaccess"). Combine that with NSCursor.current.image.size to get the visible size.

However, this isn't really an API. The old army joke goes, "If the army had wanted you to have a wife, we would have issued you one." Apple is the same. If Apple had wanted you to have a given piece of data, they would have given you an API. If you have to use hand-coded string, and query values that aren't documented and don't have enum definitions, you're taking a risk.

That being said, it does seem to work, and in a sandboxed app no less. But it looks like it would be forbidden in the Mac App Store. Any use of UserDefaults requires a privacy manifest for NSPrivacyAccessedAPICategoryUserDefaults and there isn't an entry in the reasons list for reading accessibilty settings.

Personally, I wouldn't bother with it. Don't forget the corrolary to the previous joke, "If Apple really cared about accessibility, they would have given you a decent API".