On modern macOS, how do launchctl bootstrap and bootout differ from the older launchctl load and unload, and what does a service target such as system/com.example.job or gui/501/com.example.agent identify?

## The old model and why it was replaced Original `launchctl load /Library/LaunchDaemons/foo.plist` had no way to say *where* the job should go. launchctl inferred it: root got the system domain, a normal user got their own. That inference is fine until it is not — a `sudo launchctl load ~/Library/LaunchAgents/foo.plist` puts a job somewhere nobody intended, and the classic symptom set ("loading it prints nothing but nothing runs", "it works from a terminal but not from the installer") comes straight out of the guessing. The rewritten launchctl removed the guess. ## Domain targets A domain is a container for jobs with a lifetime of its own: - `system` — exists from boot to shutdown; where Launch Daemons live; requires root. - `user/<uid>` — that user's domain. - `gui/<uid>` — that user's graphical login session; the right domain for an agent that needs the window server. - `pid/<pid>` — the domain belonging to a single running process, which is how per-process XPC services are addressed. Append a job label to a domain and you have a *service target*: `system/com.example.job`, `gui/501/com.example.agent`. Almost every modern subcommand takes one of these two forms, which is what makes the commands unambiguous. ## The verbs - `bootstrap <domain-target> <path-to-plist>` — load a job into that domain. Root and the system domain for a daemon; your own uid for an agent. - `bootout <domain-target> <path>` or `bootout <service-target>` — remove it. This also terminates the running process. - `kickstart -k <service-target>` — start it now, and with `-k` kill the current instance first. This is the honest "restart the service" command. - `print <target>` — the diagnostic dump: state, PID, last exit status, the resolved program arguments, endpoints. Far more useful than the old list output. - `enable` / `disable <service-target>` — persistent policy. ## enable/disable versus bootstrap/bootout This is the distinction that separates people who have operated macOS from people who have read a blog post. `bootout` affects the *current* domain: the job is gone now, and at the next boot or login it comes back, because the plist is still on disk and launchd loads it again. `disable` writes into launchd's persistent override database and survives reboot: a disabled service will not be bootstrapped, and an attempt to bootstrap it fails saying so. That last part explains a genuinely confusing failure — bootstrapping a service that somebody disabled months ago errors out even though the plist is perfect, and the fix is `launchctl enable` on the service target, not another look at the XML. Historically `load -w` and `unload -w` edited a `Disabled` key, and people still reach for `-w` out of habit; the persistent state now lives in launchd's own database rather than in your plist, which is why hand-editing a `Disabled` key is no longer the answer. ## Which to use Use the modern verbs. `load` and `unload` still work and you will see them everywhere in older documentation and installer scripts, but they are legacy: they infer what you should be stating, and they are quieter about failure. When you write an installer or a runbook today, `bootstrap system /Library/LaunchDaemons/com.example.job.plist` says exactly what it does, and its exit status means something. ## The interview point What is being tested is whether you understand that launchd organises jobs into domains with different lifetimes and privileges, and that a job's presence in a domain right now is a different thing from the persistent policy about whether it may be there at all. Candidates who only know `load`/`unload` usually also believe unloading a job keeps it off across reboots — and that belief is how a service everyone thought was disabled comes back after a maintenance window.