Slashdot Mirror
Are App Sizes Out of Control?
In a blog post, Trevor Elkins points out the large sizes of common apps like LinkedIn and Facebook. "I went to update all my apps the other day when something caught my eye... since when does LinkedIn take up 275MB of space?!" Elkins wrote. "In fact, the six apps in this picture average roughly 230MB in size, 1387MB in total. That would take an 8Mbit internet connection 24 minutes to download, and I'd still be left with 27 additional apps to update! More and more companies are adopting shorter release cycles (two weeks or so) and it's becoming unsustainable as a consumer to update frequently."
Should Apple do something to solve this "systematic" problem? Elkins writes, "how does an app that occasionally sends me a connection request and recruiter spam take up 275MB?"
Further discussion via Hacker News.
Should Apple do something to solve this "systematic" problem? Elkins writes, "how does an app that occasionally sends me a connection request and recruiter spam take up 275MB?"
Further discussion via Hacker News.
This is the natural consequence of choosing languages based on their library support. These languages were chosen for their ease of creating deployable solutions, not for the size of their executables.
Storage utilization is the user's problem, not the software engineer's.
The society for a thought-free internet welcomes you.
Image compression exists for a reason. If you neglect to optimize your images, the best compression in the world won't help. Check out PNGQuant; it can often achieve perceptually lossless compression through careful palette selection and dithering. Vector graphics are also a thing; you can create your bitmaps at runtime.
Node.js apps are a dime a dozen these days, and they're all fat slugs of things. Sad.
https://developer.apple.com/li...
Technical Q&A QA1779
Reducing Download Size for iOS App Updates
Q: How can I reduce the downloaded size of my app update for users that already have the previous version installed?
A: This document is specific to app updates. See Technical Q&A QA1795: Reducing the size of my App for a collection of techniques to reduce the size of an app when it is downloaded and installed for the first time.
Starting with iOS 6, the app store will automatically produce an update package for all new versions of apps submitted to the store. When generating the update package, the app store compares one or more prior versions of your app to the new version and creates an optimized package for each that contains only the content that has changed between versions of your app, excluding any content that did not change. This comparison looks at everything in the application bundle, including the application executable, nibs, localizations, image files, video files, audio files, text files, and files containing data in a custom format.
Note: The ability to create update packages is not currently available to developers who do not distribute their apps through the app store, such as those distributing enterprise apps.
When used optimally, an update package is significantly smaller to download than the full package of the app and the update will install more quickly. Also, in many cases, this mechanism allows updates to large apps to be downloadable over cellular networks where app downloads are subject to a size limit.
In addition to new content, the update package contains instructions on how to transform the prior version of the app into the new version of the app. New files will be added, modified files will be replaced with their updated counterpart, and deleted files will be removed as part of this transformation. As far as the developer and user are concerned, this process is entirely transparent and the resulting updated app will be indistinguishable from a full download of the corresponding updated version of their app.
To optimize the size of your app updates, you should consider two tips:
Do not make unnecessary modifications to files. Compare the contents of the prior and new versions of your app with diff or another directory comparison tool and verify that you've only changed what you expect within your app bundle.
Content that you expect to change in an update should be stored in separate files from content that you don't expect to change. This reduces the size of the update package and increases its install speed.
For devices running iOS 6.x and iOS 7.0, the update package will include any file, in its entirety, that has changed in the new version of the app. For example, if you have a 10 MB file in your app and only change 1 KB of content within that file in the new version of the app, the update package for that new version will contain the full 10 MB file.
For devices running iOS 7.1 and later, the update package may include only the differences between the old and new versions of a changed file instead of the full file. This may significantly reduce the size of the update package in the case where only a small part of a large file changes, but will increase the update's installation time on the device. For this reason, the two tips above are still important even for updates on iOS 7.1 and later. Minimizing changed content and localizing it to many smaller files instead of one larger monolithic file will reduce the download size in all cases and will speed up installation on devices running iOS 7.1 and later.
This is just plain overkill on UI components. ost companies are more worried about bells and whistles then functionality right now. That's why tablets and phone apps became so popular. Everything was light, small, simple which desktops and laptops really aren't. That's also my Facebook offers a slim version of their application in countries that has slow network connections.
My guess is that the pendulum will switch away from native apps to something like Progressive Web Apps (God I hate that marketing term.) Light static websites that pull from RESTful service will become popular again. The base site will be 1 meg at most in size. Until thos ebecome as bloated as native apps. Then a new disruptive technology will come along and start the process all over again.
You say things that offend me and I can deal with it. Can you?
There is a solution for Microsoft, and it's built in to Windows server. It's called Windows Server Update Services, and it does exactly what you're talking about for Windows.
Mac OS also has exactly the same thing, called Software Update services and it's included with Mac OS Server.
Neither of these are Unix based, but if you've already invested in 1000 clients, it's pretty likely you have at least one Windows/Mac OS server for all the other ancillary things they provide.
...on my Android phone. Except my phone is full, so every update... I have to delete another app, or clear the cache for it to download.
It's !#@$!ing pathetic.
I've got maybe 4 apps that aren't stock on my phone. It runs slow as piss compared to the two years ago when I bought it used. A freakin Samsung S5. You know... an "enterprise model / top-of-the-line" phone when it came out. No Facebook. Nothing. Just Google's, T-Mobile and Samsung's defaults.
"Maybe you just need to upgrade."
Bull. Shit. It's got a quad-core CPU and a GPU that would make my netbook cry, and yet... somehow... my Linux laptop sits there, every day, just as fast. And my phone keeps getting slower. Same websites. Same hardware (from purchase date). And yet... mysteriously... it keeps getting slower.
I would not be surprised at all if there's some planned obsolescence at play. I've seen countless stories of people "reseting to factory default" their phone or tablet, and then once it installed all the normal updates... it's slow as mud again. It shouldn't take me 7+ seconds to load my bloody GMAIL app on a quadcore ghz CPU. It's _e-mail_. It's practically a word processor without the word processing.
Then again, it's probably just a conspiracy theory. It's not like large corporations have ever colluded to bypass things like environmental regulations to increase profit.
Bullshit. Image sizes for simplistic apps like that would never consume that much space. The actual reason these apps are ballooning is size is because developers nowadays are complete shit and don't understand code reuse, optimisation or assembly language.
Yes, absolutely. I was just complaining to a fellow developer about this recently. As an "old school" software developer, who compiled code on an Amiga with two floppy disk drives (one for the compiler and libraries, and the other for my workspace), I am greatly annoyed by the bloat I see in apps. In my opinion, for an app to be 300 MB, it either is comprised of at least 1 trillion lines of source code, or contain a 298 MB video showing how to use the app. The latter of course being totally unnecessary. The FB app is over 300 MB. The images and icons it contains are most certainly not taking up the bulk of that space. Does it contain its own build of Linux or something? Does it contain translations for every known human language? Really, there is no reason for applications of that kind to be nearly that large.
Two things I know for sure are that iOS apps do not need to be that large - there are some really good games that are only around 5 MB. Second, and I haven't used Android in years so maybe it has changed, but a given Android app always seemed to be smaller than the iOS version.
Better known as 318230.
simplistic apps like that
how is facebook simplistic? it needs to:
track your location at all times
record everything via the mic even when backgrounded
send you push notifications when your gradeschool girlfriend makes a post about how men suck
deliver you the quality ad content you deserve
let your HR department creep on your comings and goings because they have nothing else to do
support hashtaggings
Okay, no app developer is going to use assembly, because their app will be on a range of hardware from different manufacturers. Portability is mandatory in the app world.
Total bullshit. LinkedIn, for example, is 247 mb uncompressed of frameworks and 1.6 mb of images, 14.9 mb of language localizations for the 25 languages it supports.
Actually, they ARE re-using code. These days every schmoe has a library that is "built on" some other schmoe's library. You can't even flush the urinal without going through 99 million layers of schmoe software. It's schmoes all the way down.
These clowns are worried about size -- frankly, it's a damn miracle that any of it even functions at all.
How code re-use works on a real linux distro:
1) application A wants to perform operation B
2) application A depends on libB
3) A bug in libB is discovered that prevents Application C from using it
4) Application C embeds a fixed version of libB
5) libB eventually gets upgraded while maintaining ABI compatibility
6) Application C drops its embedded version of libB and resumes sharing the system libB by depending on it with a version restriction in their next version
How code re-use works on andriod:
1) application A wants to perform operation B
2) Luckily android happens to have libB preinstalled (for argument's sake) so application A just uses it
3) A bug is discovered in the preinstalled libB that prevents Application C from using it
4) Application C embeds a fixed version of libB
5) nothing happens for a year or so until all major carriers upgrade the whole OS
6) The whole OS gets upgraded and other things in the upgrade break both application A and C even while libB gets fixed
7) The authors of application A and B say "screw this, that sucked" and embed their own copies of everything
so they never have to deal with that kind of mess again.
Someone had to do it.
OK, the numbers are "real" in that "that is how much space the app is taking on Apple's server". It is not real in that "this is not the size of the files being moved to your device."
What those numbers include: Multiple assemblies for different architecture platforms. The whole 32/64 bit thing is rearing its ugly head. There are also shared assemblies, not all of which get sent to your device (because they might already be there).
Source: I'm an app developer who has had to explain this a few times as well.
Bad User. No biscuit!
I don't miss the size constraint nature of floppies, but I do miss the portable environment nature of floppies.
It was awesome to have my own little box of 5.25 floppies that I could bring from home and then in computer class, boot the Apple ][ with my own disks and utilities.
I kind of wish it was more practical to do this with Windows. Of course there are close workalikes, (RDP, web based environments, Windows to go, etc) but nothing with the elegant simplicity of just booting the dumb thing from a 128 GB USB stick and using it as normal, and then carting it off.
It's a good comparison, except that step 6 on the Android list very rarely happens at all.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Here's something I really don't get.
The blogger - and many of the responders here - are debating the size of LinkedIn's app. But, given the bad things we know that LinkedIn has tried to do with that app on more than one occasion... why does anyone even consider having that piece of malware on their phone at all?
#DeleteChrome