An application that once arrived on a single disc now routinely runs to a download of several gigabytes. The growth is driven by packaging decisions more than by any expansion of what the software does.

One package has to serve many machines

A single release is usually compiled for more than one processor architecture, and each compiled copy sits inside the same file. The developer cannot know in advance which machine will download it.

The same logic applies to screen assets. Icons and images are supplied at several resolutions so the software looks correct on a small laptop and on a large high-density display alike.

Translated text adds a further layer, since every supported language ships with its own strings and sometimes its own fonts. None of this is visible to a user running one language on one device.

Dependencies are bundled rather than shared

Older software expected libraries to be present on the system already. That saved space but broke constantly, because two programs could need incompatible versions of the same shared component.

Modern practice is to bundle a private copy of everything a program depends on. The program then runs identically wherever it is installed, at the cost of duplicating code across every application on the machine.

Runtime environments amplify this. A program built on a general-purpose framework carries that framework with it, which is why two small utilities can each weigh far more than the operating system once did.

Assets grew faster than code

Code itself remains comparatively small. What has expanded is everything around it: video, high-resolution artwork, sound, and sample data used to make a first launch feel complete.

Games are the clearest case, because textures and audio dominate their size entirely. Even ordinary applications now ship tutorial video and illustration that would have been unthinkable when bandwidth was scarce.

Storage and connection speeds improved faster than anyone reduced these assets, so the pressure to compress them aggressively disappeared. Size stopped being a constraint that anyone was rewarded for respecting.

Delivery hides some of the growth

Stores increasingly split an uploaded package before delivery, sending only the architecture, language and screen assets a specific device needs. The download can be a fraction of what the developer submitted.

Differential updates go further by transmitting only the changed portions of files. When they work, a large application can be patched with a download measured in a few megabytes.

These mechanisms fail whenever the internal structure of a build shifts, which forces a full replacement. That is why an application occasionally demands a complete redownload for what looks like a minor change.

The incentives point one way

Nobody inside a development team is measured on package size, while everybody is measured on shipping features and avoiding installation failures. Bundling reduces failures, and features add assets.

Reducing size costs engineering time and introduces risk, and the benefit accrues to users on slow connections and older hardware who are rarely the loudest voices in the room.

The result is a steady ratchet in one direction. Sizes fall only when a platform imposes a hard limit, which is why store-enforced ceilings have done more than any internal effort.