Software updates deliver security fixes and genuine improvements. They also, with some regularity, remove features, degrade performance, or change behaviour in ways users didn't want and can't reverse.
The pattern is consistent enough to be worth describing.
The recognisable categories
Feature removal. Functionality present at purchase disappears in an update, sometimes because it was expensive to maintain, sometimes because it competed with a paid tier.
Interface changes. Redesigns that relocate familiar functions. Frequently justified by design consistency and experienced as relearning something that worked.
Performance degradation. New software with higher requirements running on older hardware. Sometimes unavoidable, sometimes a consequence of features that could have been optional.
Advertising and promotion. Features that promote the manufacturer's other services inserted into interfaces that previously didn't have them.
Restriction of third-party access. Changes that break compatibility with accessories, applications or services from other companies, generally framed as security improvements, which they sometimes genuinely are.
Cloud dependency. Local functionality replaced by something requiring an account and a connection.
Why it happens
Several structural reasons, and most aren't malicious.
Maintenance cost. Every feature must be tested against every new version. Rarely used features are expensive to keep and easy to remove, and the users affected are a small proportion who are nonetheless genuinely affected.
Recurring revenue. The shift from one-off purchase to subscription creates an incentive to move functionality behind a subscription, and updates are the mechanism.
Design consolidation. Large organisations standardise interfaces across products, which improves consistency and destroys familiarity.
Regulatory and security requirements. Some changes are genuinely required, and this justification is also available for changes that aren't.
Metrics. Changes are evaluated against measures like engagement and retention. A change increasing time in an application counts as an improvement whether or not users prefer it.
The irreversibility problem
The feature that makes this different from other product deterioration.
A physical product doesn't change after purchase. Software does, and the change is generally one-way.
Downgrading is frequently blocked — through signing requirements, through server-side checks, or simply because previous versions aren't distributed.
Automatic updates, increasingly the default and sometimes mandatory, remove the decision entirely.
Which means what you own is not what you bought, and there's no mechanism for declining a change.
The security tension
The genuine complication, and it's why blanket advice to avoid updating is wrong.
Security updates matter. Unpatched devices are exploited, and vulnerabilities are frequently public before most devices are patched.
The problem is bundling. Security fixes and feature changes arrive together, which means declining unwanted changes means declining protection.
Separating them is technically possible — several platforms have introduced mechanisms delivering security updates independently of feature releases — and it's not universal.
Where it exists it's a genuine improvement and worth seeking out in device selection.
What can be done
Delay rather than decline. Where updates can be deferred, waiting a couple of weeks after a major release lets problems surface. Security patches should not be delayed; feature releases can be.
Read release notes. Rarely done and frequently informative about what's being removed.
Check community reports before major updates. Particularly for older hardware, where performance regressions are common and predictable.
Prefer platforms with separated security updates. A meaningful differentiator that rarely appears in reviews.
Consider what happens if a service stops. For anything cloud-dependent, the question of what remains functional if the company withdraws support is worth asking at purchase.
The wider point
This is a specific instance of something general: the shift from products to services.
A product you own is fixed. A service can be changed by the provider at any time, and increasingly, physical devices are service delivery mechanisms.
That transition brings genuine benefits — continued improvement, security maintenance, new capabilities after purchase. It also means the thing you bought is subject to unilateral revision indefinitely.
Consumer protection law in most jurisdictions was written for products and adapts awkwardly. Whether removing advertised functionality after sale should be permitted is a question regulators have begun examining in some places, and it isn't settled anywhere.
Until it is, the practical position is to weight, at purchase, how much a device depends on continued support from a company whose incentives may not remain aligned with yours.
Enterprise versus consumer
Worth noting that the two are treated quite differently, and the difference is instructive.
Enterprise customers generally get update control — the ability to test, stage and defer changes, and support for older versions for defined periods. This exists because organisations demand it and can walk away.
Consumers get automatic updates with no control, because individually they have no leverage.
Which demonstrates that the capability exists and is withheld rather than being technically impossible. Some vendors have extended limited deferral to consumers under regulatory pressure, and the gap remains substantial.
One habit worth adopting regardless: before a major update, check whether the device has enough free storage. Updates that begin without adequate space can fail partway, and recovering from a failed update on a phone or a smart device is considerably harder than avoiding one.
And back up first. This is standard advice that almost nobody follows for a routine update, and the one time it matters is the one time you did not do it.