One patch, many hardware combinations
An update is not tested against one universal device. Even products with the same name can contain different processors, storage parts, wireless chips, or versions of their firmware—the low-level software that helps hardware communicate with the operating system. Manufacturers may also change components between production runs.
The operating system and its drivers, which translate software requests into instructions for specific components, have to work together. A patch can alter that interaction. If a driver expects a certain response from a chip, but a particular hardware revision responds differently, the result may be a feature that stops working, behaves erratically, or becomes unavailable. The update may function normally on another configuration because its components follow a different path.
Why automatic installation can be disruptive
Before release, updates are checked across devices and configurations, but the range of possible combinations makes exhaustive testing difficult. A problem may emerge only with a particular component, driver version, or arrangement—and only during a specific task. That makes some incompatibilities hard to catch in advance.
Automatic updates can install a patch before a user has reason to check whether others with the same configuration have encountered trouble. The convenience is that security and reliability fixes arrive without requiring a manual download; the tradeoff is less control over when a change reaches the device. The patch is the same, but the hardware-and-software combination receiving it is not.
