Your phone felt fine last Tuesday. Then a software update arrived, and now it stutters opening the camera app. The battery drains faster. Apps take a beat longer to load. You start eyeing the new model. This is not an accident, and it is not entirely a conspiracy either. The truth is more nuanced, more technically interesting, and honestly more troubling than either of those framings.

This pattern sits inside a broader web of deliberate product decisions that tech companies make every cycle. Just as tech companies deliberately make their hardware impossible to repair, the software layer gives them an additional lever, one that is invisible, deniable, and extraordinarily effective at driving upgrade cycles.

What Actually Happens When a Software Update Hits Old Hardware

Let’s start with the technical reality. Modern operating systems, especially iOS and Android, are designed around the capabilities of the hardware shipping at the time of release. When Apple ships iOS 17, its performance targets are tuned for the A16 and A17 chips. The animations, background processes, and memory management assumptions are calibrated for that generation of silicon.

When iOS 17 runs on a four-year-old device with an A13 chip and a battery that has degraded to 78% capacity, something has to give. The processor can technically execute the code, but it runs warmer, hits thermal throttling faster, and drains a battery that no longer holds its original charge. The result feels like slowdown, because in measurable terms, it is slowdown.

The controversy is not whether this happens. It is whether it is deliberate.

Benchmark performance graph showing iPhone performance scores dropping after a major iOS update release
Benchmark data published in 2017 showed performance scores clustering in lower bands after iOS updates on older iPhone models, triggering a global conversation about deliberate throttling.

The Benchmarking Evidence That Started a Lawsuit

In 2017, a developer named John Poole published benchmark data on Primate Labs showing that iPhone 6S and iPhone 7 devices running iOS 10.2.1 and later showed a striking pattern. Performance scores were not just lower on average. They were clustered in specific lower bands, as if something was capping them.

Apple confirmed what became known as “throttling”: it was deliberately reducing processor speed on devices with degraded batteries to prevent unexpected shutdowns. The company framed this as a feature protecting users from abrupt power-offs. Critics, and eventually regulators, framed it as a concealed mechanism that made old phones feel slow without telling users why.

Apple paid $500 million to settle a class action lawsuit in the United States without admitting wrongdoing. France fined Apple 25 million euros under its planned obsolescence laws. The company later added a battery health screen and a toggle to disable throttling, but only after the damage to trust was done.

The episode revealed something important. The technical justification for throttling was real. Lithium-ion batteries do degrade, and a degraded battery can cause voltage drops that crash a processor mid-task. But the decision to implement this silently, without disclosure, was a choice. And that choice had a predictable commercial side effect: it pushed millions of users toward upgrade decisions they might otherwise have delayed.

The Software Update as a Business Instrument

Once you see this pattern, you notice it everywhere. Major OS updates routinely add features optimized for new hardware while carrying background processes that older chips handle less efficiently. New visual effects, more aggressive background syncing, expanded telemetry, richer notification systems (and notification systems are rarely designed purely to serve the user). Each addition is individually defensible. Collectively, they create a performance gradient that widens with each generation.

Android manufacturers face a related but distinct problem. Samsung, Google, and others promise two to four years of OS updates for flagship devices. But writing software that performs identically on a three-year-old mid-range chip and this year’s flagship is genuinely difficult. The path of least resistance is to optimize for current hardware and accept that older devices will run the new software less smoothly.

This is not purely cynical. Software complexity does grow. Security patches do add overhead. Background processes that protect modern privacy standards do consume CPU cycles. But the economic incentives all point in the same direction, and when incentives and outcomes align this consistently, skepticism is warranted.

Battery health gauge at 79% connected by arrows to a processor throttling diagram showing reduced clock speeds
Battery degradation is the legitimate engineering trigger for CPU throttling. The controversy was never about whether it happened, but whether users were told.

How This Connects to the Broader Obsolescence Playbook

Hardware slowdown via software is one tool in a larger kit. Tech companies also control parts availability, repair documentation, and software support windows. When platform companies generate most of their revenue from users who feel trapped rather than loyal, the incentive structure becomes clearer. Keeping you on the upgrade treadmill is worth far more than keeping you satisfied with what you already own.

The right-to-repair movement has pushed back hard on the hardware side of this equation, with some legislative wins in the US and EU. The software side is harder to regulate because degraded performance on older hardware can almost always be attributed to legitimate engineering decisions rather than deliberate sabotage. Proving intent is nearly impossible when the technical cover story is plausible.

What You Can Actually Do About It

A few practical things are worth knowing.

First, battery health is the real variable. On iPhone, check Settings > Battery > Battery Health. If you are below 80%, replacing the battery (now easier and cheaper than it used to be following regulatory pressure) will often restore most of the performance you have lost. The same logic applies to Android devices from manufacturers that expose battery health data.

Second, you can often delay OS updates without security risk for a few weeks, which gives you time to check whether early adopters on forums report performance regressions on your specific model before you install.

Third, treat major OS updates released alongside new hardware launches with particular attention. The timing is not random. Apple and Google release new operating systems in the same window as new devices because it benefits the narrative around those devices. Your upgrade decision and their product launch are meant to feel connected.

Finally, understand that some slowdown is real engineering constraint, not malice. A five-year-old phone running a modern OS will struggle regardless of anyone’s intentions. The question is whether the company is being honest with you about what is happening and why, and whether you have been given the tools to make an informed choice.

The companies that sell you hardware have always had more information about its trajectory than you do. What has changed is that we now have benchmark data, regulatory proceedings, and settled lawsuits that show exactly how that information asymmetry gets used.