RunningBoard has its origins on iOS [1] and was brought to the Mac as an implementation detail of Mac Catalyst [2]. It has neither a direct API nor any ‘user serviceable parts’ [3]
I’m not sure whether RunningBoard assertions are related to your WKWebView
media problems — I’m not an expert on WebKit or the media subsystem — but I can guarantee you that you won’t be able to fix them via the com.apple.runningboard.assertions.webkit
entitlement. That is, as I mentioned above, an Apple-only thing.
As to what you should do, my advice is that you start a new thread that describes the actual issue you’re having, tagging it appropriately in the hope of attracting attention from folks who are WebKit and media subsystem experts. If that doesn’t pan out, open a DTS tech support incident so that one of my colleagues can help you directly.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] The internal name for the Home screen on iOS is SpringBoard, and over the years various ‘board’ subsystems have been split out into their own processes, RunningBoard being one of them.
[2] As to what it does, note that the article you referenced has misinterpreted the term assertion. To quote the runningboardd
man page:
runningboardd
is a daemon that manages process assertions to ensure
those processes are kept in the appropriate state while assertions are
in effect.
In this context an assertion is something that a process raises to tell the system about its state. For example, a UIApplication background task asserts that the app must not be suspended. Indeed, I use this terminology in my UIApplication Background Task Notes post. It would be reasonable to assume that RunningBoard forms the back end of that API when you call it from a Mac Catalyst app (although I must admit that I haven’t investigated whether that’s actually the case :-).
[3] To continue quoting that man page:
There are no options for runningboardd
, and users should not run
runningboardd
manually.