the update finished. the work it started did not.

why a macOS update is not over when the progress bar is

the installer replaces the system and nothing else. everything that depended on the old one — search indexes, compiled graphics code, analysed photos, security scans — is now out of date, and none of it is rebuilt during the install. it is queued for later.

«later» is not a timer. macOS hands deferred work to a scheduler, and the scheduler releases each job only when it has the budget for it: the Mac is on power, idle enough, and not already hot. that is the whole mechanism, and it explains both halves of the symptom — why the machine is busy when you sit down, and why a laptop shut every night can stay slow for a week.

the scheduler is real: shortly after login it starts «gathering its budgets enabling it to score activities, including thermal policies, shared memory and energy». every background job is scored, and only the ones that clear the bar run. the eclectic light company — in the background: software update, backup & XProtect Remediator

you usually meet the queue in the storage graph first: the difference between old indexes and new sits under the label «System Data», and right after an update it is mostly this work, still in progress: find out what system data is using

what is actually running after a macOS update

five jobs account for almost all of it. the names below are what a current Mac reports in Activity Monitor — several repeated elsewhere were retired versions ago.

Spotlight rebuilding its index

the largest job on most Macs: mds_stores, corespotlightd and a row of mdworker_shared — there is no standalone mdworker any more. it reads every file the index covers and, for images and PDFs, extracts the text inside them. that extraction is the expensive part, and after an upgrade it can start over from nothing.

the scale is documented: several recent upgrades made indexing «take prolonged periods, in some cases reported as several days». on Apple silicon nearly all of it runs on the efficiency cores, which is why it can feel worse than it looks in the CPU column. the eclectic light company — in the background: Spotlight indexing

photos analysing the library again

photolibraryd, photoanalysisd and mediaanalysisd, running together. a new version of Photos means new face, scene and text recognition, and the library is walked again to apply it. it runs only on power and only when Photos is not in use, so it is the job you notice on a machine that was left alone — and on tens of thousands of items it is measured in weeks, not hours.

the reader's wording for this is «analysing scenes», and one thread reports a library of 53,000 photos taking three weeks with the Mac kept awake day and night. Apple community — photoanalysisd has been running for 6 months

every app recompiling its shaders

the one nobody lists, and the reason apps feel sluggish on first launch specifically. GPU code is compiled on your machine and cached; a new OS ships a new graphics stack, and the cached binaries no longer match it. so the first time each app opens after the update, its shaders are built again — the process is MTLCompilerService, and on this Mac five of them sit idle, waiting for work.

Apple says it in the session on shipping games to the Mac: «when your players update their OS, their binary archives may require recompilation», and Metal «upgrades them automatically in the background after an OS update». wwdc23 — bring your game to Mac, part 2: compile your shaders

a security scan and the first backup

• XProtect Remediator scans for known malware — xprotectd and XprotectService in Activity Monitor. it runs at roughly 24-hour intervals, only on mains power and only when the Mac is lightly loaded, so a freshly updated laptop on battery postpones it.
• Time Machine's first backup after an upgrade is larger than usual. it waits five minutes after startup, then competes with everything above for the disk.

none of these are visible in the memory column, which is why the memory graph stays green through all of it — it is measuring something else entirely: what memory pressure actually measures

why kernel_task is at the top after the update

sort Activity Monitor by CPU during the first day and kernel_task is often the first row, at a number that looks like the answer. it is not. kernel_task is the throttle: when the chip gets hot, macOS parks work inside it to hold the other processes back. it is near the top because the jobs above have been running for an hour, not because it is doing anything itself.

Apple's own page is explicit: kernel_task «helps manage CPU temperature by making the CPU less available to processes that are using it intensely» and «does not itself cause those conditions». Apple — if kernel_task is using a large percentage of your Mac cpu

the fan is late for the same reason

the fan follows the same heat with the same lag: it starts after indexing has run a while and keeps going after the job finishes, because the metal is still warm. a loud fan on the second morning after an update is the queue being worked through, not a sign the update went wrong.

the lag is worth understanding on its own, because it is why the noise never lines up with what is on screen: why your Mac's fan is loud when nothing is running

whether the machine is under thermal pressure now, rather than ten minutes ago, one line answers without sudo: notifyutil -g com.apple.system.thermalpressurelevel. zero means it is cooling; two or above means a job is live and still winning.

watching that reading and the process list together over an hour is what a menu bar monitor is for — it names the job while it runs, not after: system monitor for Mac

why a Mac update takes an hour to settle on one Mac and a week on another

the «24 to 72 hours» every page quotes is a guess at how long a typical Mac spends in the state the scheduler needs, and that state has three conditions. a laptop breaks all of them routinely.

• asleep, nothing runs. a MacBook closed at ten and opened at eight got zero hours of background work. the queue is where it was.
• on battery, the big jobs wait. photo analysis and the security scan both require mains power; a Mac awake and idle all afternoon on a couch makes no progress on either.
• hot, everything slows. the scheduler scores thermal budget, so a Mac already throttling under the indexing pass gets less of the other jobs, not more.

put together: a desktop left on and plugged in is done by morning. a laptop used on battery by day and shut at night can carry the same queue for a week, and each morning feels like the update happened yesterday. no setting fixes that. one night plugged in, lid open, sleep prevented, and the backlog clears.

why «reinstall macOS» does not help

the second most common advice is to reinstall, and it is the one thing guaranteed not to help: it replaces the system again and queues the same work again from the start. safe mode is a better diagnosis — it boots without third-party login items, so fast there means something you installed is slow, and still slow there means the queue.

the reading that tells you whether it is heat or something else is not a temperature — an Apple silicon Mac will not give you one — and that has its own page: check cpu temperature on an Apple silicon Mac

when slow after an update is not the update

give it one full night on power with the lid open. still slow after that, the queue is no longer the explanation, and what is left are ordinary causes that happened to arrive with the update.

• an app not ready for the new OS. a menu bar utility or helper polling something the system changed can sit at 30% CPU indefinitely. Activity Monitor names it; its own update fixes it.
• an app running under Rosetta. it works and costs more power for the same work — the update did not cause it, it just moved the fan into earshot.
• a disk that was nearly full before the update and is fuller now. swap has nowhere to go, and everything that needs memory waits.
• one app whose memory grows and never comes back. that is a leak in that app, not a Mac problem, and a new version is the only fix.

the first case had a season of its own this year, when the menu bar changed underneath the apps living in it: what macOS 26 changed for menu bar apps

the third case ends in a specific dialog, and what ran out is not what the dialog says: fix «your system has run out of application memory»

frequently asked questions

why is my Mac so slow after updating macOS?

the update replaced the system and queued everything that depended on it to be rebuilt: the Spotlight index, the analysed photo library, every app's compiled graphics code, a security scan. those jobs run only when the Mac is on power, idle and not hot — a day on a desktop, a week on a laptop shut every night.

how long does a Mac stay slow after an update?

one night plugged in with the lid open clears almost all of it. the «24 to 72 hours» figure assumes normal laptop use, which interrupts the work constantly.

why is kernel_task using so much cpu after the update?

it is the throttle, not the cause. when the chip gets hot, macOS parks work in kernel_task to hold other processes back. look one row down for the job that made it hot.

should i reinstall macOS if it is slow after the update?

no. a reinstall replaces the system again and queues the same rebuild again. boot into safe mode instead: fast there means a third-party login item, still slow means the queue.

why do apps take so long to open after updating?

each app's GPU code is compiled on your Mac and cached, and the new OS invalidated the cache. the first launch after an update rebuilds it — MTLCompilerService in Activity Monitor. the second launch is normal.