Part of it is resolution. The icons and such in apps are much larger now than they were in 2013. Besides that I mentioned this in another thread but rarely will a team clean up after itself. There's probably tons of dead code and what not in a lot of these larger apps. I know all the ones I've worked in had a lot of bloat just from years of work. Some feature gets added 5 years ago by a team that no longer exists, it was turned off and no longer used but who is going to remove it?
Besides that, there's just a lot of garbage that gets added by various people with different interests. An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.
> An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.
Frameworks from other companies. A lot of it is analytics/tracking, some payment processing, etc. There are a few open source libraries we're using as well but those probably are <5mb if I had to guess although I never checked.
Again, a lot of these companies have also been around so if my app has a ton of bloat from years of work, we're bringing in frameworks from other companies who have been around for years as well and probably have a similar amount of crap in their code. Plus they probably want to track everything we're doing so they're bringing in their own third party libraries. It's kind of ridiculous but that's where we're at.
Bigger companies won't have as many third party libraries as they can afford to do it in house but they're still bringing in similar sized libraries to do the same things.
Imagine, it's not just making sure your code is secure, but your also counting on all those libraries's being secure. Let alone all these frameworks as you say - payment, advertising, analytics... You could have the most secure code ever, but when it is just one link in a chain outside your control, best not overthink it or you won't sleep.
You can see why bug bounties get rewarded well. Though mindful, money is not what drives everyone. Then there are the greedy, in which such exploits value on the black market can be higher. Not forgetting government agencies level.
I wonder which email client will break the 1GB mark, and when we will see a resurgence in reducing bloat. I'm sure that phase will come, did for Microsoft once.
Woof. This is just so wild if one ever stops to think about it. ~300mb of tracking for a single app is bigger than the entire hard drive of a fully internet-capable desktop computer in the mid '90s.
Huh, is there a requirement that they be rasterized at build time? If I had a choice, I'd rather ship the SVGs in the bundle alongside a renderer like ThorVG and render at runtime. The renders could even be cached if the rendering itself was expensive.
If you’re including these assets as UI elements, they would be rasterized anyway and copied to a GPU bound buffer for the frame blit. Doing so at compile time increases runtime performance.
You can of course override this behavior and redraw your vector every 8.3 ms if you want, but I promise you that this is not faster. For sparse pyramid-tiled vector images like Google/Apple maps, this is a two step process using the latter method followed by the former.
Historically, raster graphics won out because they used less resources. Perhaps that's changed. If so, it would make sense for various OS's to start working on native support. Irix did it in the 90's. It can be done now.
Yeah but I would argue that they just used cheaper ressources since historically has been cheaper than compute.
It's not clear if compute can be cheaper than storage still today.
On one hand you can afford to use less storage but you have to use GPU power everytime to draw graphics, if the chip can support the compute requirement you can save on storage, but you pay with higher power draw at every interraction.
On the other hand you can just put more storage, chip assest that are rendered for the device they'll be used on and be ok.
Outside of crisis like now, storage should be cheaper in the long term I think. I doubt there is that much benefit in having assets being able to resize to any arbitrary resolution. The definition used in phones isn't that far away than what is used in laptops, monitors and now even TVs.
Something to think about is that icons/assets often need to change shape slightly as they become smaller or bigger for optical reasons. So even if you manage a fully vector scaled UI, you might still need to have difference depending on DPI to reading distance ratio. Rasterized assests might still be the real answer for a very long time.
Considering how bad is the iOS 26 release on performance, because of its dynamically computed interface, I'm not sure it's worth pursuing vector UIs, it doesn't make a lot of sense to make a more powerfull chip just to draw prettier or more "pure" interfaces...
we've been able to "preserve vector data" with pdf and svg image resources on ios for a long while now... compile-time rasterization is the default though...
Besides that, there's just a lot of garbage that gets added by various people with different interests. An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.