How iCloud can be simpler than a server
Apple provides so many services for different parts of macOS that it’s hard to keep track of them. If you want to see a short summary, this article lists all service connections for enterprise network administrators, although it doesn’t detail which services use which servers, for example referring to “macOS updates” in many entries.
Many of you seem surprised to learn that Sequoia’s new XProtect updates come from iCloud, although Apple has been using iCloud for similar purposes for at least the last five years.
One good example that’s used every day on your Mac are the notarization checks sometimes run by Gatekeeper when macOS launches executable code, such as an app. In that case, com.apple.syspolicy
processes the app’s notarization ticketlooking up ticket: <private>, 2, 1
by trying to fetch its record from iCloud using CloudKit. That’s followed by log entries indicating the network access required to connect with iCloud and check the ticket. Success is reported by com.apple.syspolicy inCKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
looking up ticket: <private>, 2, 0
and further lookups. I first reported those checks with iCloud back in Catalina, in 2019.
A simple way to illustrate the differences between this and using the general softwareupdated
service is to compare what happens in the log when you ask if there are any updates available.
softwareupdate
When SilentKnight does this, it uses the only supported method, the softwareupdate
tool, as used to keep XProtect up to date in all versions of macOS prior to Sequoia. That command hands over to the softwareupdated
service to run the check. That in turn uses components of com.apple.SoftwareUpdateController
to summarise the update state of that Mac, connect to the Software Update Server, check all the current versions and build numbers of macOS and its ancillaries, and arrive at a list of updates required. This is even more complex than it sounds, as com.apple.SoftwareUpdateController
has to check key settings such as whether the root volume is sealed or not.
You can trace this through several thousand log entries, and after around 4.4 seconds and multiple network connections, softwareupdate
finally informs SilentKnight that there are no updates available.
xprotect
Running the commandsudo xprotect check
in Sequoia is far simpler and quicker, as it checks for just one component’s updates through iCloud. The command connects to XProtectUpdateService in the XprotectFramework private framework in macOS, which in turn fires up CloudKit to connect to iCloud. That fetches a database record and returns the result to XProtectUpdateService, and so back to the xprotect
tool as its result. Total time taken is 0.5 second.
As Apple’s intent in changing the management of XProtect and its data appears to be to facilitate more frequent and macOS-specific updates, iCloud is an ideal platform to host this on.
Pinniped with tusks
There is, though, one last thing: what is the walrus? As that might seem an odd question, read these two log entries encountered when browsing what happened with the xprotect check
command:
12:08:00.919841 com.apple.cdp XPC Error while fetching walrus status: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process.}
12:08:00.919845 com.apple.cloudkit CoreCDP reports that walrus is undetermined for the logged in account. Error: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=<private>}
The prospect of an undetermined walrus that can’t be fetched from inside my Mac might seem worrying