An update is announced, a friend installs it immediately, and your device insists it is up to date for another week. The delay is deliberate and it is a safety mechanism.
Shipping to everyone at once removes the ability to stop
Testing before release catches the failures a developer thought to look for. It cannot reproduce the full range of hardware, network conditions, languages and installed software in the wild.
Some defects only appear at scale. If the release has already reached every device, the damage is complete before anyone has measured it.
Staging the rollout keeps the majority of users on the previous version while the new one is observed.
The early group functions as a control group
A small percentage of devices receives the update first, and their behaviour is compared against everyone still on the old build.
Crash rates, battery drain, app launch times and error responses are watched side by side. Because both populations are live at the same moment, external factors affect both equally.
If the new group looks worse on any monitored measure, the rollout is paused before it widens.
Each wave is larger than the last
Rollouts typically expand in steps, with a holding period between them so that slower-emerging problems have time to surface.
Battery and storage issues in particular need days of normal use to show up, which is why the gap between waves is measured in days rather than hours.
A clean run reaches everyone within a couple of weeks. A problem found in wave two can send the build back to engineering entirely.
Cohorts are chosen, not random
Selection usually accounts for device model, chip generation, region, carrier and sometimes language, because those are the dimensions along which failures cluster.
An older handset with less memory is a more informative test than the newest one. Manufacturers also stagger by carrier when the carrier certifies builds itself.
This is why two people with the same phone model on different networks receive the same update days apart.
Server-side flags decouple release from delivery
Much of what users experience as an update is not shipped code at all. Features are already present in the installed app and switched on remotely.
That lets a feature be withdrawn instantly without asking anyone to install anything, and it means the visible change and the download often arrive on completely different schedules.