Over the last decade macOS has changed beyond all recognition. While we’re all familiar with some of the most overt changes, such as the APFS file system, security and privacy protection, and the loss of 32-bit code, there have been many internal changes. Among those is the adoption of DAS, Duet Activity Scheduler, and its consort CTS, Centralised Task Scheduling, to manage and schedule background activities. Before they were tentatively introduced in OS X 10.10 Yosemite, recurrent background tasks like Time Machine backups were run by the clock through launchd, itself a replacement for cron and a whole lot else.

I’ve been studying and analysing DAS and CTS since I first stumbled across them over nine years ago, in macOS 10.12 Sierra. They have inevitably changed much over that time, and in Apple silicon Macs are now largely responsible for the work done by their Efficiency cores. This article describes how DAS gets going after a restart, its scope of work, and how Time Machine backups are initiated now.

Information is drawn from a Mac mini M4 Pro running macOS 26.5.2 Tahoe, making hourly local Time Machine backups.

DAS initialisation

I initiated the restart at time 0, and there followed this sequence of events, time being given in elapsed seconds, corrected according to the adjustments made to the system wallclock:

• 12.238177 system boot
• 17.581032 corecrypto kext starts, startup chime sounds
• 21.526884 launchd started
• 21.951414 system wallclock time adjusted
• 38.984633 login button pressed
• 46.426357 DASDaemon initialising
• 46.448995 first activity submitted to DAS, and registered

Times after the start of launchd are slower than you may experience, because there’s a delay while its external backup storage is mounted. These compare with macOS 10.12 Sierra, where DASDaemon initialised 3 seconds after system boot, here more than ten times later. But in the days of Sierra booting was such a quick and simple process.

Activity submissions

With DAS up and running, it’s ready to receive submissions of activities to be scheduled. These normally start with the event being added to CTS, here referred to by the subsystem com.apple.xpc.activity, and for each to be submitted and registered. This is the first:
46.448995 com.apple.xpc.activity Creating on XPC add event: com.apple.softwareupdated.logs-cleanup
46.449115 com.apple.xpc.activity Created: com.apple.softwareupdated.logs-cleanup (0xc30c39400)
46.449252 com.apple.duetactivityscheduler SUBMITTING: 0:com.apple.softwareupdated.logs-cleanup:A2BBC8
46.566769 com.apple.xpc.activity Registered: com.apple.softwareupdated.logs-cleanup (0xc30c39400)
In subsequent log entries, that will be referred to as
0:com.apple.softwareupdated.logs-cleanup:A2BBC8
where the leading 0 is the user ID, here root, and the trailing hex A2BBC8 is its DAS identifier, which you can use to track that activity in subsequent log entries.

Among many others are the three activities required for Time Machine backups,
46.610284 com.apple.duetactivityscheduler SUBMITTING: 0:com.apple.backupd.analytics:7601E0
46.610464 com.apple.duetactivityscheduler SUBMITTING: 0:com.apple.backupd-auto.dryspell:3597C5
46.610615 com.apple.duetactivityscheduler SUBMITTING: 0:com.apple.backupd-auto:3F0129

DAS also apparently loads some activities that have been saved earlier, and asks for resubmissions:
47.541842 com.apple.duetactivityscheduler Loading saved activities.
47.555702 com.apple.duetactivityscheduler Soliciting activities for resubmission.

During this, login is completed and the Desktop and Finder displayed at about 58 seconds.

The number of activities handled by DAS has risen greatly over these years. You can read my previous summaries about Sierra and Catalina, where there were far fewer.

In macOS 26.5.2, in the 72.5 seconds during which I recorded activity submissions, there were at least 701 non-identical activities submitted, from com.apple.AccessoryUpdater.UARP.firstBootFirmwareCheck for root, to com.apple.XProtect.PluginService.agent.slow.scan for user 501. If you really want the full list, please contact me.

While submissions are still being made, DAS starts to schedule and despatch activities to be run.

Time Machine scheduling

I have looked several times in detail at how DAS and CTS schedule and despatch Time Machine backups using backupd-auto to avoid accruing time delays. In essence, the activity managed by DAS and CTS triggers the backup to be performed, quits and is rescheduled shortly afterwards, so ensuring the next scheduled run of backupd-auto is an hour after the previous run started, rather than after completion of the backup.

Prior to macOS Sonoma, the configuration file com.apple.backupd-helper.plist has been set with an interval of 3600 seconds, 1 hour, and that was then used to determine the scheduled time for the next run of backupd-auto. This changed in Sonoma, when Time Machine became able to schedule backups less frequently. To accomplish this, as I’ve described, the interval has been reduced to 1800 seconds, 30 minutes, which might appear paradoxical.

What happens now is interesting, and has implications for other LaunchAgents and LaunchDaemons.

About 1 second after the 0:com.apple.backupd-auto:3F0129 activity was submitted to DAS for its lists, it evaluated whether to run it then:
47.592432 com.apple.duetactivityscheduler Submitted: 0:com.apple.backupd-auto:3F0129 at priority 30 with interval 1800 (Thu Jul 16 16:57:46 2026 - Thu Jul 16 17:17:46 2026)
47.592609 com.apple.duetactivityscheduler 0:com.apple.backupd-auto:3F0129:[{name: Boot Time Policy, policyWeight: 0.010, response: {33, 0.00, [{[Minimum seconds after boot]: Required:300.00, Observed:29.56},]}}], Decision: MNP}
DAS therefore decided not to proceed with the backup because it was less than 30 seconds since starting up, when it had to wait 300 seconds, 5 minutes, before making that first backup.

On this occasion, the first backup was started by backupd-auto at about 17:20:00, and backupd-auto was then submitted to DAS for its next run at an interval of only 1800 seconds, and that was given the identifier 0:com.apple.backupd-auto:EBA7D4.

That first backup completed in about 2 minutes, following which backupd-helper loaded system preferences and presumably discovered the user had set those for hourly backups. backupd-helper then set the criteria for com.apple.backupd-auto to comply with that setting, and Time Machine rescheduled the next backup to take place in an hour:
17:20:02.853363 backupd-helper com.apple.xpc.activity xpc_activity_set_criteria: com.apple.backupd-auto (0xb42c303c0), dict
17:20:02.853393 com.apple.TimeMachine Re-scheduled next backup in 60 minutes (plus or minus 30 minutes)

That was submitted to DAS as a new activity, and the existing 0:com.apple.backupd-auto:EBA7D4 was cancelled
17:20:02.854499 com.apple.duetactivityscheduler SUBMITTING: 0:com.apple.backupd-auto:1A54C2
17:20:02.858743 com.apple.duetactivityscheduler Submitted: 0:com.apple.backupd-auto:1A54C2 at priority 30 with interval 3600 (Thu Jul 16 18:12:46 2026 - Thu Jul 16 18:42:46 2026)
17:20:03.257442 com.apple.xpc.activity Canceling: 0:com.apple.backupd-auto:EBA7D4 (CTS Activity 0xc30d78c80)
17:20:03.258225 com.apple.duetactivityscheduler CANCELED: 0:com.apple.backupd-auto:EBA7D4 at priority 30
That leaves the next backup to be scheduled in an hour, rather than the 30 minutes set in com.apple.backupd-helper.plist.

This demonstrates how property list settings given in LaunchAgents and LaunchDaemons can be modified on the fly, and shouldn’t be assumed to be those seen in the property list.

Key points

• DAS and CTS are now are now largely responsible for the work done by Efficiency cores in Apple silicon Macs.
• DAS typically initialises after user login, then starts adding activities to be scheduled.
• In macOS 26.5.2, DAS submits at least 701 non-identical activities for scheduling.
• backupd-auto, which triggers Time Machine backups, is set to do so every 30 minutes, but that is modified to meet user settings by cancelling scheduled runs at default intervals, replacing those with runs at intervals set by the user.
• Scheduling settings in LaunchAgents and LaunchDaemons can readily be overridden.