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…
To be fair, Threads is almost certainly built with React Native which always leads to bigger app bundles. Not to say that there isn’t anything fishy in there, but that’s part of the reason.
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.
Just different tech used most likely. Mastodon is a native app and Threads probably something like React Native, so it has a JS runtime inside and a bunch of dependencies.
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.
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…
I think it’s because threads is just a new front end for instagram. It’s just instagram with a twitter skin applied to it.
To be fair, Threads is almost certainly built with React Native which always leads to bigger app bundles. Not to say that there isn’t anything fishy in there, but that’s part of the reason.
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.
Just different tech used most likely. Mastodon is a native app and Threads probably something like React Native, so it has a JS runtime inside and a bunch of dependencies.
This is the equivalent of suspecting one of two books to be containing Nazi propaganda because it has more pages in it.
I’m not saying you should not be suspicious of the content of Threads but using size as a metric for it seems nonsensical to a software dev.
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.