Environment: macOS 26.5, M4 Pro, native SwiftUI app (no MTKView/game render loop; it does use SwiftUI Metal shader effects).
There's a related scheduling puzzle underneath: my app's worker threads are confined to E-cores for work that runs on P-cores from a CLI.
The game computes AI decisions with brief CPU-bound bursts of parallel tree search. The identical library, doing node-count-identical work, runs ~6× slower inside the app than from a CLI on the same machine — the difference is core placement, not the workload. And since several bot decisions run in sequence each hand, that 6× stacks into user-visible seconds at the table:
CLI process, default QoS: ~54ms per decision (P-cores) GUI app, worker threads at .userInitiated and .userInteractive: ~350ms (E-cores) Reproducible from the CLI with taskpolicy clamps: utility ≈ 92ms, background ≈ 584ms The app declares LSApplicationCategoryType = public.app-category.card-games and GCSupportsGameMode = true, and runs native full screen as the frontmost app on Apple Silicon — but Game Mode never engages (no menu-bar controller icon).
Questions:
What are the actual activation criteria for Game Mode? Is a game-style render surface (e.g. MTKView/CAMetalLayer) required beyond the Info.plist declarations? Is E-core placement for a GUI app's non-main-thread compute intended scheduler policy even at userInteractive QoS? What is the supported way for a GUI app to run brief, user-blocking compute on P-cores — is Game Mode the intended lever, or should I be looking at something like os_workgroup?