Why do app updates have download sizes almost as large as the apps themselves?

Submitted ⁨⁨1⁩ ⁨year⁩ ago⁩ by ⁨zirzedolta@lemm.ee⁩ to ⁨programming@programming.dev⁩

They seem to be too big for what devs claim to be a ‘minor patch’ and yet too small to suggest a complete reinstallation of the app. Is there some technical reason behind it? I would like to request an ELI5 for this.

source

Comments

Sort:hotnew top

RagingHungryPanda@lemm.ee ⁨1⁩ ⁨year⁩ ago
App stores and their systems don’t usually have the ability to deploy diffs, so the whole package goes out

source
- ono@lemmy.ca ⁨1⁩ ⁨year⁩ ago
  
  App stores and their systems don’t usually have the ability to deploy diffs
  
  Google Play has had this ability for over a decade. IIRC, they call it smart updates, though the general idea is often called delta updates.
  
  source
lightsecond@programming.dev ⁨1⁩ ⁨year⁩ ago
The Google Play Store uses a technique called delta patching to calculate the diff server side and avoid transferring parts of the app that haven’t changed since your original installation.

This is understandably not perfect because they want to avoid load on their servers and also the extra processing on your device to “unpack” it. So what you have is a happy medium between sending the entire app again and sending strictly the diff.

source
Darkassassin07@lemmy.ca ⁨1⁩ ⁨year⁩ ago
Because you’re literally re-downloading the entire app, tossing the old version, and installing the new.

It’s not modifying existing files with the changes, it’s just replacing the package completely (while keeping config/user files).

source
- zirzedolta@lemm.ee ⁨1⁩ ⁨year⁩ ago
  Lol I thought at first devs calculated exactly what portions of the apps need updating and uploaded only that much portion in the app stores. I dunno what to make of this discovery now.
  
  source
  - Darkassassin07@lemmy.ca ⁨1⁩ ⁨year⁩ ago
    That can get really convoluted, especially when users update at different times from different past versions.
    
    One user may be able to make the most recent changes as they have the most recent version not including the update thats being pushed right now; another user however may be 15 revisions behind and have to find and apply each of those 15 updates in the correct order to arrive at the same set of files.
    
    It’s much easier to just push the most recent set of files in their entirety to users and have them replace whatever they’ve got. Then you know they didn’t make any mistakes applying several subsequent changes in a row.
    
    source
  - wildbus8979@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
    That’s fairly easy to do for interpreted languages, but it’s a lot more problematic for compiled apps that are distributed as a machine code binary.
    
    source
  - noddy@beehaw.org ⁨1⁩ ⁨year⁩ ago
    I think windows update does that, or at least used to do. That’s why it is so slow to update, because you need every update in succession, you can’t just grab the latest one.
    
    source
dallen@programming.dev ⁨1⁩ ⁨year⁩ ago
This will completely depend on how and what is being distributed.

For example, I used to work on an app where assets (3D models, images, etc) were appropriately diff’d during updates but the binaries were not.

source
adespoton@lemmy.ca ⁨1⁩ ⁨year⁩ ago
The reason they’re smaller is that they’re compressed, and expanded during the install process.

For most platforms, the product update is vetted and signed as a functional program, then compressed to save space in transmission, then decompressed and validated prior to swapping with the original.

OS updates and DLCs are available to add new data to an existing system, but this isn’t generally used for discrete parts of a functional program due to the potential for abuse or errors.

source