A major version update needs about two days. A point release needs about an hour. We measured both on the same machines, and the gap between them is larger than almost anyone assumes — on a major update a benchmark run the same evening sees roughly a third of the speed you will eventually get, while on a point release the machine is essentially done before you have finished making coffee.
That is the answer. The rest is the evidence: what an Apple device is actually doing in the hours after an update, how we logged it minute by minute, and how you can tell when your own machine has finished without taking our word for it.
The short version
| Major version (iOS/macOS 26 → 27) | Point release (27.0.1 → 27.2) | |
|---|---|---|
| Background indexing | median 25.7% CPU, still running at 9 hours | two bursts, about 7 minutes in total |
| Disk consumed | 7–14 GB | 1 GB |
| Quiet 20 minutes in? | no | yes |
| Benchmark stable from | roughly 2 days | roughly 1 hour |
| What a day-one test shows | about a third of the real gain | the real result |
What a major update is doing while you wait
When iOS 27 and macOS 27 shipped in September 2026 we updated five devices and watched them. The work that runs afterwards is Spotlight re-indexing, photo analysis and app optimisation, and it is not subtle.
On a MacBook Pro with an M1 Pro we caught the indexing in progress and sampled its CPU use: 9.6%, 10.5%, 25.7%, 34.1%, 34.9%. On a 16-inch M5 Pro the indexing processes were still running nine hours and nine minutes after the install finished — six mdworker processes and one photoanalysisd. That machine lost 10.4 GB of free disk space. A 14-inch M4 Pro lost 7.3 GB by the morning and another 6.7 GB by that evening, with nothing installed in between.
This is why the phone feels hot and the battery drops faster for a couple of days after a big update, and it is also why a benchmark taken on the first evening is misleading.
How wrong is a day-one benchmark?
We have an exact answer for this, because we measured the same iPhone 17 Pro four times across the same update.
| Time since update | Speedometer 3.1 (median of 3) | vs iOS 26.6.2 |
|---|---|---|
| before — iOS 26.6.2 | 43.2 | baseline |
| 1 hour 54 minutes | 47.3 | +9.5% |
| 23 hours 30 minutes | 52.3 | +21.1% |
| 47 hours 30 minutes | 54.5 | +26.2% |
A verdict formed two hours after updating would have reported +9.5%. The real figure was +26.2%. The early number is not wrong as a measurement — the phone genuinely was that fast at that moment — it is wrong as a description of the update, because the phone was still busy with itself.
Note also that the gain was still climbing at 47 and a half hours. We stopped measuring there, so +26.2% is a floor, not a ceiling. That is where our “about two days” comes from, and it is a minimum rather than a precise threshold. The full write-up of that update is in should you update your iPhone to iOS 27, and we measured the re-indexing window itself in more detail here.
A point release is a different animal
We had assumed the same advice carried over to point releases. It does not, and we were able to check because macOS 27.2 arrived while we were set up to watch for it.
We installed it on the 16-inch M5 Pro and logged two things once a minute from the moment the machine restarted: the combined CPU use of the indexing processes (mds, mdworker, photoanalysisd, photolibraryd, backupd, installd) and the free space on the boot volume. The first 79 minutes of that log are unbroken.
| Minutes after install | Indexing CPU | Busiest process |
|---|---|---|
| 15–35 | about 0% | — |
| 36 | 104.7% | mdworker_shared |
| 37–64 | about 0% | — |
| 65–70 | 89.7% → 108.0% | photolibraryd |
| 71–79 | about 0% | — |
Seven minutes of real work, in two bursts, and 1 GB of disk consumed against 7–14 GB for the major update. The machine was quiet twenty minutes in, busy again at 36 minutes, and properly busy for six straight minutes starting at minute 65.
That last detail is the practical one. The biggest burst did not arrive until more than an hour after the install, so “it looked quiet, I tested it straight away” is still not good enough. But you do not need to set aside two days.
A second device says the same thing
An iPad Pro 13 (M4) gives an independent read on this without any process logging at all, just from how its benchmark runs behave.
| iPad Pro 13 (M4) | Run 1 | Run 2 | Run 3 | Spread |
|---|---|---|---|---|
| iPadOS 27.0 (major, during indexing) | 47.40 | 51.10 | 51.58 | 8.2% |
| iPadOS 27.2 (point, settled) | 53.03 | 53.03 | 53.60 | 1.1% |
On the major update the runs climb and the confidence interval narrows each time (±3.4, then ±0.98, then ±0.31). That is the shape of a machine finishing something in the background while you test it. On the point release the runs are flat from the first one.
How to tell when your own device has settled
You do not need our numbers. On a Mac, open Terminal and run this:
ps -Ao pcpu,comm | grep -E 'mdworker|photolibraryd|photoanalysisd|mds' | sort -rn | headIf the first column is near zero, nothing is indexing. If you see numbers in the tens or over 100, wait. Run it a few times over an hour rather than once, because the bursts are intermittent — ours was silent for twenty-eight minutes between its two bursts.
On an iPhone or iPad there is no equivalent readout, so use the benchmark itself as the instrument: run it three times a couple of minutes apart. If each run is faster than the last, the device is still working on something and none of the three numbers describe it. If the three runs are flat, you are looking at the real performance.
Common questions
How long does it take to update to iOS 27?
The install itself is typically twenty to forty minutes depending on your connection and device. The part people forget is what comes after: on a major version jump the device keeps working on itself for at least two days, and it will feel warmer and use battery faster during that time. On a point release that tail is about an hour.
How long should I wait before judging an update?
Two days for a major version, one hour for a point release. Our iPhone was still gaining speed at 47 hours after a major update, and a judgement made at two hours would have understated the result by about two thirds.
Is it safe to install a point release straight away?
From a settling point of view, yes — there is no multi-day penalty to absorb. That is a separate question from whether a given release has bugs, which we have not tested and cannot tell you.
Does a point release make my device faster?
Not in our measurements. The same iPhone 17 Pro measured 53.0 on iOS 27.2 against 54.5 on iOS 27.0, both taken after the device had settled. That is a difference of −2.8%, and our detection floor on this phone is 5.3%, so we read it as no change rather than as a loss.
Why does my phone get hot after an update?
Because it is re-indexing your files and re-analysing your photo library. We measured that work at a median of 25.7% CPU on one Mac and found it still running nine hours in on another. It is temporary and it is not what the new version is like afterwards.
What we have not tested
- One point release, on one Mac. The macOS 27.2 log is a single machine through a single update. The iPad corroborates the pattern but through a different kind of evidence.
- We logged process CPU and disk, not what was being indexed. We can say the machine was busy and for how long; we cannot say what it decided to re-index.
- Battery, on any device. We did not measure it and will not estimate it. The “drains faster for a couple of days” claim here is inference from the CPU numbers, not a battery measurement.
- No macOS 27.2 speed figure. Our Mac was benchmarked twenty minutes after installing and fifteen minutes after a reboot, while the figure it would be compared against came from a machine that had been running for days. That difference flatters the new number, so we are not publishing it.
- Beyond 79 minutes on the point release. The log continued for eleven hours but the laptop slept intermittently, leaving gaps. Every point-release number above comes from the unbroken first 79 minutes.
If you are deciding whether to take a major update at all rather than when to judge it, we worked that through on a specific device in should you update your iPhone 17 to iOS 27, and compared five devices across the same update in what iOS and macOS 27 did to five Apple devices.
Major-update figures measured September 2026 across an iPhone 17 Pro (MG7K4LL/A), an iPad Pro 13 (M4), and MacBook Pros with M1 Pro, M4 Pro and M5 Pro, moving from iOS/iPadOS/macOS 26 to 27. Point-release figures measured 7 November 2026: macOS 27.2 (26B123) installed at 11:29 local time on a 16-inch M5 Pro, with indexing-process CPU and free disk space logged once a minute from restart; iPadOS 27.2 and iOS 27.2 benchmarked five days after install. Speedometer 3.1 in Safari via browserbench.org throughout, three runs two minutes apart, other apps closed, Low Power Mode off, median of three reported. Mobile devices on battery with brightness fixed at 50% and auto-brightness off; Macs on the charger.