If there’s a Cinderella in macOS, it has to be loginwindow. While it has its moment of glory when it provides the one window we all have to use, to log in, it does a great deal more work behind the scenes, which passes largely unacknowledged. Browse the log for the seconds immediately after you’ve logged in and you’ll see what I mean: every other entry is from loginwindow as its sets everything up for the newly logged-in user. It’s a proper application too, found in /System/Library/CoreServices, so part of the Signed System Volume (SSV) in Big Sur and later, even though it isn’t allowed a distinctive icon. Poor Cinders!

Startup

After the kernel and launchd, loginwindow is probably the third most important process to run in macOS, although it’s not given a distinctive process ID. It’s run by launchd late during the boot process, once sufficient system services have been loaded and prepared for control to be handed over to a user.

Its most obvious task is to prepare, display, handle and destroy the user login window. This is shown following every startup (not in special modes such as Recovery), except when auto-login is configured (only permitted when FileVault isn’t enabled), and the reboot performed at the end of installing a macOS update.

Once a valid user and password have been entered, and FileVault has been unlocked together with the login keychain, loginwindow gets to work creating the user environment, loading up user processes, configuring all user settings, and loading key apps to create the GUI environment, including the Desktop, Dock and Finder. It’s also responsible for loading user Login Items.

With the bulk of its work complete, loginwindow still isn’t done, and you’ll find it as an active process in Activity Monitor, as it persists until the Mac is shut down. It’s then responsible for handling the Force Quit dialog, together with logout, restart and shut down actions.

It works closely at times with TAL, the macOS Transparent App Lifecycle, which helps it restore sessions across reboots using the many folders containing saved states in the ~/Library/Saved Application State folder. You’ll also see TAL active in the log as the subsystem com.apple.talagent.

App startup

Among everything else that’s going on when you open an app, loginwindow does its bit too. This involves creating a new active tracking timer, and checking the app in. You may also see its log entries referring to ‘snapshots’, although those are saved states of the app, not APFS snapshots. In conjunction with TAL, loginwindow keeps track of background and foreground apps, and maintains a list of apps to be relaunched in the event of a restart or shutdown. Those records are removed when the app is quit.

Shutdown

When the user chooses a command to log out, restart or shut down the Mac, that sends an AppleEvent to loginwindow, which displays the normal confirmation dialog. If the user confirms the action, loginwindow is then responsible for quitting all user processes. For apps, this in turn results in each calling their applicationShouldTerminate code, or receiving an AppleEvent to quit. They are then given 45 seconds grace to reply or quit, after which their termination sequence is stopped, leaving the user to handle that app in a Force Quit dialog if necessary.

Background processes are first sent an AppleEvent, then loginwindow sends them a SIGKILL signal to finish them off. System daemons should receive a SIGTERM signal initially, followed a few seconds later by SIGKILL. Once all processes have gone, loginwindow initiates the logout, restart or shutdown as appropriate.

Not only is loginwindow there in its full glory at the start of the user phase of startup, but it’s there until the bitter end.

Reference

Apple’s Daemons and Services Programming Guide, last revised in 2016.