We normally get to know about new features of macOS and iOS at WWDC in early June each year, just as Apple releases the first developer betas of the operating systems it’s going to unleash that autumn/fall. One notable omission this year was a substantial new subsystem which I’ve been taking a first look at over the past week or two: RunningBoard.

If you’ve ever noticed your Mac become very sluggish, almost unresponsive, and peeked in Activity Monitor to discover that some component of Safari is stealing 100% of CPU, you may be interested in what RunningBoard could do to prevent that. In this first incarnation, it seems capable of managing apps (and other processes) to control their lifecycle (whether they nap, sleep, or quit), limit the amount of memory they consume and the amount of CPU they get allocated, and their use of GPUs in graphics cards (and eGPUs).

At the moment, this seems to apply only voluntarily, and is primarily available to Apple’s own apps rather than those of third-party developers. At some time, either during Catalina’s development cycle or, more likely, in macOS 10.16 and iOS 14 or later, I suspect that Apple will open RunningBoard’s features more widely.

Browsing interfaces to the Private Frameworks which macOS Catalina and iOS 13 contain, RunningBoard and its services are extensive, but currently inaccessible to third-party developers, as there’s no public framework or entitlements available. My earlier thought that they might use standard assertions as explained here on Wikipedia has kindly been refuted in an anonymous comment here, and the more that I see of the subsystem’s activities in the log, the more obvious it becomes that these are quite a different kind of ‘assertion’.

We’re already used to our apps being managed. Sandboxed apps from Apple’s App Store are run in their Sandbox, and have an explicit list of entitlements which determine what they can do beyond its tight confines. Mojave introduced, and Catalina has extended, strict limits of private and other sensitive data which apps can access. The Unix foundations of macOS have a pervasive system of permissions to determine which processes can read and write files.

For some processes, management is already sophisticated. Those such as periodic Time Machine backups are scheduled and despatched using two subsystems, DAS (Duet Activity Scheduler) and CTS (Centralized Task Scheduling). Although much of the time these work unseen in the background, iOS at least has used them in more controversial ways to control energy use and performance.

With the advent of more demanding real-time features such as Virtual and Augmented Reality, more sophisticated mechanisms are needed to ensure that those don’t get put on pause while some background Spotlight indexing process has an attack of the ab-dabs, or an errant photo app decides it’s more entitled to the CPU and GPU. Apps can also go into contention for data resources, and end up with one locking the other out, causing great user frustration.

Interestingly, the latest release of Safari Technology Preview extends support for WebGPU, a future Web standard for accelerated graphics and computation being promoted strongly by Apple and others. Many more apps are also starting to contend for access to your Mac’s GPU.

As far as I can see at the moment, RunningBoard tracks every app, and processes which it may use, perhaps via XPC. Open Safari and browse a couple of pages in Catalina, and you’ll see a great many log entries from the subsystem com.apple.runningboard. But so far, all the apps that I have looked at, including Music, are tracked but not managed by the subsystem. Perhaps at this stage of development, that is all that is supported on macOS.

One thing that RunningBoard doesn’t seem be concerned with is security, nor privacy for that matter. If one of the security services, such as Gatekeeper, decides to force an app to exit because it doesn’t meet current security policy, then RunningBoard is informed about this, and may well appear in the crash report. But this new sub-system isn’t (as far as I can see) involved with making such security decisions, nor with terminating the app.

It will be interesting to see how RunningBoard develops, particularly when it’s managing processes which are competing for resources on heavily-loaded Macs.