One of the unannounced surprises which came in Catalina was a whole new sub-system, RunningBoard. I described my early impressions, and discovered how it was important for Catalyst apps. What no one outside Apple knew at that time was that, within the year, M1 Macs would be running native iOS and iPadOS apps, for which RunningBoard is expected. With the arrival of Apple Silicon Macs, RunningBoard is now doing a great deal, and has come of age. This article looks briefly at what it does in Big Sur 11.2.3.

All supported Macs running Big Sur can (in this context) run two classes of app: regular unmanaged apps, and those built using Catalyst.

For unmanaged apps, little seems to have changed with RunningBoard. The sub-system registers all apps, and keeps track of what it terms their ‘assertions’, but doesn’t attempt to manage any of their resources, such as memory, CPU or GPU usage, or their lifecycle. It appears to act as a commentator rather than controller.

Catalyst apps are different (in other ways too!), in that RunningBoard takes an active role in managing them. My example Catalyst app opted in to the existing macOS scheme for dealing with memory pressure, allowing RunningBoard to set its Jetsam priority to 0, putting that app first in line to be quit if macOS were to come under memory pressure. Other controls exerted by the sub-system include ‘aggressiveness’, idle time and its sleep timer. These involve FrontBoard’s Watchdog, and its monitoring of the app’s resource allowance. This is altogether much more like RunningBoard’s role and behaviour in iOS/iPadOS.

M1 Macs

M1 Macs now add a third class of app: those written for iOS/iPadOS and running natively within Big Sur.

RunningBoard engages early in the launch of iOS/iPadOS apps, and declares in the log that the process will be managed, noting its HOME and TMPDIR paths. It then tracks the app process, acquiring assertions, just as it does for Catalyst apps. Initially, RunningBoard sets its Jetsam priority to 0, its Darwin role to Background, GPU priority to ‘deny’, and CPU limits to defaults.

The iOS app is then brought to the front and made active, which is registered by RunningBoard. Its Darwin role is updated first to UserInteractiveNonFocal, then to UserInteractiveFocal. It’s next given a higher Jetsam priority of 10, with a GPU priority of ‘allow’. It’s at that stage that FrontBoard registers the app as a process, and creates its workspace, which it appears to term a ‘scene’, a familiar term to iOS developers. FrontBoard creates a ProcessWatchdog for the app and allocates it 1200 seconds of resource. The last of these new -Board sub-systems then comes into play, FuseBoard, which tracks windows and their states and creates an NSMenuBar ‘scene’.

Differences between the management of iOS and Catalyst apps are relatively small. Both rely on several assistants, with which RunningBoard may also interact. These include the UIKitSystem app, the daemon CoreServicesUIAgent, and others possibly including itunescloudd, assistantd and (via XPC) NSAttributedStringAgent.

Requirements

Memory management differs greatly between macOS and iOS. Macs generally have ample memory and storage space, so hand out memory generously, knowing that if they start running short of physical memory then they can call on virtual memory. The situation in iOS is completely different: iPhones and iPads have relatively little memory – even an iPhone 12 Pro Max only has 6 GB, and there are no options for more – and can’t use swap space because of the more limited life and capacity of their storage. So iOS/iPadOS is frequently under memory pressure, and has a system known as Jetsam which is used to kill processes to recover their memory. This isn’t optional either, but part of the rules.

Since Mac OS X 10.7, Macs have had a mechanism for tackling situations when they come under memory pressure: memorystatus and the enableAutomaticTermination option. These allow a process to be terminated automatically when macOS needs to free up more memory, and that process is idle. Unfortunately, in macOS, processes have to opt into this system, and as a result it appears to be little used.

For both Catalyst and iOS/iPadOS apps running on macOS (and presumably others opting in voluntarily) their Jetsam priority determines when RunningBoard might need to kill that app if required, to free up physical memory for processes with a higher Jetsam priority. Similar considerations apply to other resources, such as CPU time and GPUs.

The Darwin Role sets the class of process, whether the user is able to interact with it, and whether it’s at the front or in the background. The apps tested here don’t explicitly access the GPU, so weren’t set to contend for that as a system resource. They were also given default settings for access to the CPU. Once those are done, RunningBoard marks that app active. It’s next brought to the front, and its Darwin Role changes to RoleUserInteractiveFocal to reflect that with another assertion.

UIKit in macOS

One of the fundamental differences between apps developed for macOS and those developed for iOS/iPadOS is their central class framework. In macOS, that’s AppKit, which provides basic app support, documents, and the human interface, including accessibility support. Its equivalent in iOS/iPadOS is UIKit. The two systems have some very different concepts and capabilities. For example, AppKit’s interface is centred on windows, views and menus, while UIKit has interface scenes, as managed by FrontBoard.

UIKitSystem, which first appeared in Mojave, is a background app which interfaces with an iOS or Catalyst app’s use of iOS services and bridges from them to macOS. Catalyst apps also have direct access to AppKit to enable their macOS versions to work and interact more like dedicated macOS apps, but UIKit is intended to provide a common core for them both.

RunningBoard and the M1

Initial configurations of Apple Silicon Macs, the first M1 models, have in some respects been specified more like iPads than traditional Macs. They have limited and fixed physical memory, and the penalty for heavy use of virtual memory is shortened working life of their internal SSDs, which like memory are fixed and essentially neither upgradeable nor replaceable. In portable Macs, CPU and GPU usage come at significant energy cost too, and there will be times when more than one process is contending for them. For many apps, the resource management services of RunningBoard make as good sense in macOS as they do in iOS.

These are still early days for RunningBoard in macOS. Even major apps within macOS like the Finder don’t yet invite RunningBoard to manage them. But we should expect this to grow in the future, extending beyond just Catalyst and iOS apps running on Apple Silicon systems. I think that RunningBoard has quite a future.