The thing I noticed right out of the gate when I went slumming on Threads is that the Android app package is 77MB. Compare that to Mastodon at 2.5MB.
Two apps that (from the user’s perspective) do pretty much the same thing - make queries to servers and display pieces of text on the screen, maybe with some pictures or videos. Not that hard.
So what does that extra 74MB of bloat in the Threads app do? Meta’s not telling us…
Tbh bloat usually has nothing to do with tracking or something. Additional code is actually super light-weight. To add full tracking and stuff, we might be looking at a few 100kb additional size.
Using fat frameworks like react native adds much more size. Maybe another 5-10MB.
But what really takes a lot of space is animations, images, background images and stuff like that. A high-res image might take multiple MB on it’s own. Multiple of them will take much more.
Edit: I just downloaded and unpacked the newest thread’s version’s APK and unpacked it.
It has an upacked size of 143MB, of which 83.7MB are assets.
The compiled code including framework and all is 56.9MB. The rest (2.4MB) are metadata.
Mastodon has an uncompressed size of 4.3MB of which 2.4MB are code.
As mentioned in other comments, tracking logic is going to be so negligible at those sizes that it’s not even worth talking about - it’d be like 100kb at worst.
The problem is Meta is extremely inefficient in writing mobile apps. They solve many problems by just chucking libraries at them, but those libraries are “jack of all trades” type libraries. They use React which is abysmally large, and tons of their own monolithic garbage.
When you write an app from scratch, you only use the pieces you need. Meta is an absolute monolith with years and years of code that’s been added over time and it’s easier to just “copy/paste” most stuff they’ve ever written than to start over.
