Live data from Hacker News

App sizes are out of control

trevore.com

161–170 of 455 posts

Re: App sizes are out of control

#161

Earlier quoted context omitted.

I work on Amazon Prime Photos iOS app. It's currently 60mb in size, and a good chunk of that is the Swift runtime. Even the main Amazon shopping app is less than 100mb.

I'll bite. In what ways can you use up 100MByte with a fancy reimplementation of an online shop ? That should be enough for a text to speech engine, or a 3d engine with quite a few assets. I am being deliberately ignorant, having no idea what functionality one might add, but I'm actually genuinely curious. All that I see is a small databse and a lot of assets that are being downloaded on the fly.

I believe it does have a text to speech engine......the Android app has one.

Re: App sizes are out of control

#162
Is anyone else worried about the massive amounts of bundled third-party libraries that come with each app from a security, rather than a size, perspective? What happens when such a library receives a security patch? AFAIK it's up to each developer to keep all bundled libraries up-to-date, which means that, realistically, everyone is shipping lots of vulnerable stuff and they don't even know it.

"This shirt is dry clean only, which means it's dirty."

Re: App sizes are out of control

#163
post #152

I have been replacing traditional apps with PWA's or mobile websites wherever possible (on Android). They hardly take up any space and also seem to behave well (drains less battery) compared to traditional apps. I could replace the following with PWAs: - Twitter - Uber - Lyft - Google news - Instagram - Flipboard - Shopping sites like Walmart, Wish and many more. Facebook and Amazon have no PWA's but have mobile webs…

What exactly is the difference between a PWA and a mobile website?

Branding, obviously. :)

Re: App sizes are out of control

#164

The problem is it's not really in Apples interest to get app sizes smaller. Larger apps means you have more "need" to upgrade your phone to the latest version with more space, power, speed etc.

While that sounds like a clever trick that Apple could use, they really want to minimize production costs and maximize utility for consumers. Their profit margin comes from a share of that surplus utility.

I suppose it can help hide price increases of the next higher configurations, such as when the base configuration of the MacBook Pro decreased from 256GB to 128GB between 2016 and 2017, with the list price for 256GB configurations increasing by a couple hundred dollars. However, Apple has also gone as far as developing an entirely new filesystem to decrease storage use.

Re: App sizes are out of control

#166
post #70
post #52

Earlier quoted context omitted.

> I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality. Fwiw, this is already a trend in JavaScript land. Libraries are moving towards many small packages so you can import only the parts you need either manually or using a tool…

I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy). What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link…

If you want "just pull in the things I use" you can already get that by having a static library, and if you were going to be shipping a private copy of the .so file in your app then surely you would be better off with a static library -- you don't get any of the benefits of the DLL (sharing with other apps, can update the DLL without shipping a new copy of the whole app), so why pay the cost of it?

(If you link against the static library then the linker pulls in only the .o files that the app used, so assuming that the library was written in a sensibly modular way you pay only the binary size cost for more-or-less what you use. The linker can probably discard at a finer granularity than whole-object-file these days, but only-the-.o-you-use has been there for decades.)

Re: App sizes are out of control

#167

It's pretty rich how these companies are well known for the rigor they apply to interviewing candidates on technical subjects, yet actually drop the ball in production with poor engineering like this. Where does that rigor go after the interviews are done? Are there any examples of well-known apps from large organizations that aren't excessively large in size?

It's hard to move fast and have a well engineered product.

Re: App sizes are out of control

#168

The reason the LinkedIn app is so big is the number of frameworks they use. 87 frameworks accounting for 248MB of the 277. The swift runtime takes up about 20MB, and something called VoyagerFeed takes up over 190. All the images actually only make up about 12MB. There's also about 0.5MB for each localisation.

>something called VoyagerFeed takes up over 190

"LinkedIn’s new flagship app, nicknamed “Voyager,” is a complete architectural and design overhaul available for iOS and Android, as well as an online mobile experience, in the coming weeks." https://thenextweb.com/apps/2015/10/14/linkedin-voyager/

Sounds like "VoyagerFeed" may be part of their own codebase.

Re: App sizes are out of control

#169
post #94

Earlier quoted context omitted.

You could use static analysis to find out if anything calls objects dynamically by name at run time which could be a useful optimization. To be safe this would be one bool value for the entire code base, but with some care it would help. A larger issue is size is simply not considered a significant issue.

With Objective-C, that will always come back "true." Even if you never use dynamic lookups, Apple's frameworks do. I suspect the same is true of other languages.

Interesting, I find that surprising due to the overhead involved. In most languages calling functions via string names is very expensive.

PS: Do you have an example?

Re: App sizes are out of control

#170

Those numbers are mostly unfair. For some reason in the iOS 10 App Store, Apple started listing the complete fat (both 32-bit and 64-bit archs) submitted .ipa size. If you want to easily test that, clear your cellular data usage, update one of those apps (or install) and then go back to settings and see the actual bytes transferred. Also, most everyone is using Swift in some small part, so that automatically includes…

I'm curious, does anyone have the equivalent app sizes on Android? I'd love to see a comparison, to see if this is more of a platform issue as mentioned in a few comments, or a developer issue.

I guess we also should be looking at the actual data transferred rather than the number shown on the store page.

Post reply on HN