[KaedeTai]

Every Neptune/virgl render context runs in its own render-server worker process. None of them runs an AppKit event loop, so without LSBackgroundOnly each worker gets a Dock icon and is reported as "Not Responding" while a VM with GPU acceleration is running (a Windows guest with D3D11/D3D12 opens dozens of them).

This sets INFOPLIST_KEY_LSBackgroundOnly = YES for the QEMURenderServer target (Debug and Release).

Testing: Tested by a human on macOS 27.0 (26A428), MacBook Pro M5 Max (Mac17,6) with a Windows 11 ARM guest using GPU acceleration: before the change the Dock filled with "Not Responding" QEMURenderServer icons; after it no render-server icons appear and the VM runs normally.

The author acknowledges that this change has been tested and/or reviewed by a human in accordance with UTM's AI contribution guidelines.

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

[osy]

That's weird, I've never hit this issue. Can you reproduce this on a stock install (ie inside a new macOS VM)?

[KaedeTai]

Thanks, good call. I tried the stock 5.0.8 release on the same Mac (bundled D3DMetal 3.0) and can't reproduce it either: none of the render-server workers is registered with LaunchServices (lsappinfo list).

The difference is D3DMetal. My build uses D3DMetal 4.0b3 from the Game Porting Toolkit 4 beta. With 4.0b3 the x86_64 workers are registered as type="Foreground" (10 of ~20 for a Windows 11 guest), which is what puts them in the Dock as "Not Responding". On the same build, swapping in D3DMetal 3.0 makes them disappear, and with LSBackgroundOnly and 4.0b3 they register as BackgroundOnly instead.

So this only matters once UTM moves to a newer D3DMetal (or for anyone building with one). It is harmless with 3.0, but feel free to close it if you'd rather handle it when you update D3DMetal.