I’m building SumoGUIMac, an open-source native macOS GUI/viewer for Eclipse SUMO traffic-simulation workflows. The reason I am doing that is because sumogui has serious on Mac issues and is unusable in Tahoe and I need this program for my MSc dissertation. It’s written in SwiftUI + Metal and connects to a normal user-installed SUMO runtime over TraCI. It can currently open configuration files, launch or attach to SUMO, step/play simulations, render lanes/junctions/live vehicles, and inspect selected objects.
It’s still work in progress but I’d really value feedback from Swift/macOS developers on the app architecture, Metal rendering path, packaging, and how to make it easier for people to try !
Out of curiosity (this is the first time I heard about SUMO), does this mean SwiftUI app and SUMO runtime (I believe this is the simulation engine) are two separate processes and they communicate via TraCI, a TCP based API? If so, what are the commands sent by the engine to draw graphics like? I consulted AI and was told that the original sumogui and the engine are built into a single binary file so their communication are direct function calls.
Cool project. Also curious though why you chose XPC over TCP when libsumo seems to be the supported high-performance / high-stability path for what you need.
Yes, that’s basically right. It currently runs as a separate native macOS app and either launches sumo --remote-port ... itself or attaches to an already-running SUMO TraCI server. The communication path is TraCI over TCP.
SUMO is not sending drawing commands to the app. The rendering is custom. I parse the .sumocfg / .net.xml side for static geometry, build Swift-side model objects, and render lanes/junctions/vehicles with Metal. Each simulation step updates live state through TraCI commands/subscriptions: vehicle position, angle, speed, type, lane/edge IDs, selected-object variables, etc. For now I’m using TraCI subscriptions/bulk updates rather than per-object polling.
I started this as on my macOS Tahoe setup, the existing sumo-gui is effectively unusable because of visual/rendering bugs. That’s not a criticism of SUMO itself, which is excellent, but the FOX/OpenGL GUI stack did not feel native, even when it worked.
Small correction: I’m not using XPC for the SUMO boundary. The current backend is plain TraCI over TCP.
I chose that for alpha mostly for packaging and workflow reasons. Keeping SUMO as a separate user-installed runtime means SumoMacGUI does not bundle SUMO binaries, does not have to solve C++/SWIG/dylib integration immediately, and avoids a lot of macOS signing/notarization complexity while the app is still in alpha. It also lets the app attach as an additional viewer client to an already-running SUMO experiment/controller process, which is important for my own traffic-control/RL workflow. In that setup SumoMacGUI is just the native macOS visualization/control surface, not the owner of the whole simulation stack.
I agree libsumo is probably the right thing to evaluate for an embedded/high-performance backend later. For now I’m reducing the TCP cost by using subscriptions/bulk updates rather than per-object polling.
As I wrote above, the existing sumo-gui is effectively unusable on Tahoe because of visual/rendering bugs. That’s not a criticism of SUMO itself, which is excellent, but the FOX/OpenGL GUI stack did not feel native, even when it worked.