Developers Explain Why iOS Apps Are Getting Bulkier (ndtv.com) 140
Reader joshtops shares a report: Apps are getting bigger in size, in part because developers add new features, something many users obviously appreciate, developers say. "Apps are getting bigger because iOS devices are more powerful, and developers are building more and more complex things for them without considering the impact the size will have around the world," developer Stephen Troughton-Smith tells Gadgets 360. But in part, it is also happening because developers are being careless, and adding more than one instance of files, Troughton-Smith added. "So Facebook, Twitter, and other large companies have perhaps tens or hundreds of people building their iOS apps. A lot of the components for these apps are developed independently as components, or frameworks. For each additional component you glue together into an app, there is some overhead," he explained. "Some of the teams will duplicate functionality some other team wrote. Images and other resources end up being duplicated." The high-resolution image assets that developers are required to add also contributes to the size of an app, two India-based developers, and Peter Steinberger, founder and CEO of PSPDFKit, a dev kit that is used by several popular PDF apps, told Gadgets 360. Apple can itself take some blame, too. Developers using Apple's Swift language, which the company introduced in 2014, are required to add several components to their apps that make them heavier. "Apple's new Swift language, for example, requires a bunch of components to be embedded each time it's used, because it's not yet 'ABI stable,'" Troughton-Smith explained. This means developers need to embed the versions of libraries they've developed against, and not count on the one available on the system. Another developer who didn't want to be identified said a typical app built with Swift language requires as many as 30 Swift runtime libraries to be stuffed within the app. On top of this, he added, "you will be surprised at just how many apps use common code found at places like GitHub. Developers often don't care about removing the bits that wasn't relevant to their app," he added.
In a blog post published in June, marketing and research firm Sensor Tower wrote, "The total space required by the top 10 most installed US iPhone apps has grown from 164 MB in May 2013 to about 1.9 GB last month, a 12x or approximately 1,100 percent increase in just four years." The phones' storage capacity has not changed at anything close to the same rate, with the base iPhone version only recently going up from 16GB to 32GB of storage." [...] San Francisco-based developer Ben Sandofsky, who was part of the team that made Twitter's iOS app and has served as a consultant on HBO's Silicon Valley show, resonated our concerns and said often "employees at these [Western] companies live in an 'early adopter bubble.' They have LTE connections, fast Wi-Fi at home, and phones with 64 gigs of storage. This creates a huge blind spot around your average user." Sandofsky, who recently developed popular third-party Halidi camera app for iPhone, added, "another issue is advances that have made the lives of engineers and managers easier, without understanding the burden on users. It's gotten easier than ever to reuse code between iPhone apps. With a few keystrokes, an engineer can add thousands of lines of code to an app. In theory that's good, because engineers shouldn't reinvent the wheel. Unfortunately things have gotten crazy in the last few years, with engineers pulling gigantic libraries that add megabytes to their app's size, when they could build something much smaller to solve the task at hand in under an hour."
Swift Compiler (Score:3)
Re: (Score:2)
My thought too. If a function is never used, it should be elided from the final linked binary.
Re:Swift Compiler (Score:5, Interesting)
The Swift optimizer can perform high-level optimizations, but to use the high-level abstraction of built-in Swift data structures in Swift Intermediate Language, the developers need to understand how the Compiler performs those optimizations.
My guess is that the developers lack that understanding of the Compiler's SIL optimization.
Re: (Score:2)
Re: (Score:2)
TFS also claims that Swift programs can't count on stable libraries, so they have to include their own runtime libraries. That's perfectly reachable code that shouldn't have to be there.
Re: (Score:2)
In OO languages it is a bit difficult to see which code is truly unreachable, unless for obvious cases, of course.
Re: (Score:2)
Actually, for pure Swift code, it's rather easy, as compiler optimizations go. The problem is the dynamism of Objective C.
Re: (Score:2)
Re: (Score:2)
No, they are not.
E.g. with overridden virtual methods, you usually have to link all of them as you can not statically decide which will be called in the end.
Re: (Score:2)
Not even close. Not when programmers can do things like:
id object = [[NSClassFromString(@"SomeOtherClass") alloc] init];
id result = [object performSelector:NSSelectorFromString(@"someMethod")];
It's theoretically possible to catch all of those tricks, but easy, it ain't.
Shit management. (Score:1)
This is all about sloppy architecture - as in not having one - and shitty project management.
It looks like they have a bunch of separate teams with their own direction and no one sitting down and really designing the things.
it has nothing to do with the compiler or tools. Shit like this happens on poorly managed projects all the time regardless of language, tools, platforms, etc....
See folks, good management does have its place.
Re: (Score:1)
Doesn't it prune unreachable code?
If you have hundreds of megabytes of unreachable code, then you have bigger problems than your compiler.
Re: (Score:2)
Since we launched Halide, the most unexpected compliment we’ve heard is about its size. At 11 megs, we’ll push less data in one year than a social network pushes in a single update.
“So you aren’t using Swift,” asked a friend. After all, Swift bundles its standard libraries into your app, bloating its size. Halide is almost entirely Swift.
Re: (Score:2)
From the article. I got the device can handle it, so we can be sloppy.
I really don't need a high resolution image of a solid blue box, with a logo taking 1/4 of it. Just show the logo, and put it behind a vector image of a blue box.
Most of my more complex apps on my phone actually take much less size, then a glorified web browser app. Just because it was coded to do something, and not just so they can say it is a Mobile App. And force you to use that then a normal webpage, because you used your phone to
Redirect (Score:2, Insightful)
No mention of the very real problem of analytics/trackers. Once you get Crashlytics and all the other trackers stuffed into there you're pushing 200MB without any real functionality.
Contrast this with Signal; the most recent update was around 30MB, and it incorporates complex crypto and video calls. Not so many trackers.
Re: (Score:1)
Re: (Score:1)
In Other Words... (Score:1)
Developers are sloppy, lazy, NIH-prone sods who'll slap together as much crap as they can get away with because the prevailing wisdom is that developer time is more valuable than resources and time wasted by their millions of users. We knew this, we just hadn't realised the math is that flawed. Because, hey, who needs more than one app on their phone, right?
Re: In Other Words... (Score:2)
They are lazy, but they haven't been NIH people for quite some time - in fact, NIH is anathema to the truly lazy developer.
The pinnacle of laziness for software development is finding some library or framework already on the Internet that does what you need to do in the particular situation you are in, and you import the whole bloody thing without so much as looking at all the other shit it brings along with it. Do this 30 or 40 times and glue it together with the flavor of the week language and ship it wi
I have three words for you. (Score:2)
Dynamic link libraries.
Tim Cook should talk to this guy named Bill Gates, he might know a bit about them.
Re: (Score:2)
The developers are lazy. The linking model isn't the problem. You can duplicate native code with dynamic linking or with static linking.
Or are you suggesting moving more functionality into the platform's standard library?
Re: (Score:2)
iOS requires Apps to be static linked.
There is no dynamic linking AFAIK.
Re: (Score:2)
That hasn't been true for several years now. The real issue are the Swift runtime libs that have to be included because the ABI isn't stable.
Re:I have three words for you. (Score:4, Insightful)
As far as I understand it, you can not install a shared library to be used by more than one App.
A App itself can have an *.so in its lib folder, so.
The only true shared *.so's are those provided by Apple and preinstalled on the iOS device like UILib.
Re: (Score:2)
Read the summary. The issue with Swift is that the libraries are not locked down yet. Each app has to static link - or include the libraries as part of the installation - as it can't rely on the different versions being compatible.
Re: (Score:2)
The whole idea of mobile apps is that they are self contained. Using shared libraries (unless they are included in the OS) is the exact opposite of what people want. And if you think about Windows, it did start with shared DLLs, but nowadays it keeps a different version of the very same DLL available for each program, to prevent DLL hell.
Shared libraries only work if you have a single source, such as a Linux distribution. Otherwise they are more hassle than it is worth.
Unexpected benefit (Score:4, Interesting)
I have a 16GB iPhone 6. It was a mistake to go for the lowest tier of storage, and I regret it, but it DOES make me choosy about my apps. I have a 32GB 5th Gen iPad and just by the nature of what I do on my phone vs. my iPad, that's actually just fine. I install the big games on my iPad, aggressively delete anything I'm bored with, and that's great.
On my iPhone, I'm now ultra vigilant about what I use, which means I don't have facebook installed, which is GREAT. (I still use it, just in the browser.) I've gotten rid of the apps that are huge and distracting, and while I'm still always toeing the line with regards to storage, I'm happier with this low-storage situation than I expected. And when I finally get a new phone with more storage, I think I'm going to TRY to keep the same mindset, and keep my phone's installed app base nice and lean.
Re: (Score:1)
I have a 16GB iPhone 6. It was a mistake to go for the lowest tier of storage, and I regret it
It was also a mistake to choose a phone without expandable storage.
Re: (Score:1)
That is the larger mistake, in my opinion.
Being able to use memory cards and being able to change the battery are two of my "won't buy if I can't" features when I'm shopping for a phone.
Re: (Score:2)
I don't need to swap batteries until my current one no longer keep its charge so I don't really care if the battery is "removable" as long as I can open the phone with tools and replace the battery.
What I don't like is that it is sometimes hard to find original quality batteries 3-4 years after launch which aren't overpriced or sold by obscure ebay sellers.
Re: (Score:2)
I don't really care if the battery is "removable" as long as I can open the phone with tools and replace the battery.
I count that as "removable". Just not conveniently so. But there are too many phones that don't even allow that, with batteries glued and/or soldered in.
Re: (Score:2)
at least on the Nexus 5, it was pretty easy to "unglue" the battery and replace it.
Re: (Score:2)
Last I looked, Apple would change the battery for eighty dollars, and there were lots of places charging less. The iPhone battery is removable, just not conveniently so.
Re: (Score:2)
If I can't remove it myself with, at worst, a commonly available screwdriver then it's not removable in my book. The idea is that if I drain or damage my battery, I can put a new one in without a lot of fuss.
By the way -- $80?? That's simply insane.
Re: Unexpected benefit (Score:1)
I think it's a mistake to pick Android because of the overall junkier experience. But see, I recognize this as an *opinion*, not a fact. You could adopt this attitude as well...
Ditto. (Score:2)
Same here with my very old iPhone 4S with its 16 GB of RAM. Also, have to conserve its original old battery and slowness. I also use it when I have to.
Image Bloat (Score:2)
Re: (Score:1)
Dynamic libraries? (Score:3)
Dynamic libraries have been one way to save space for programs. Have a standard library that is tossed into a special shared area of the filesystem, hard link it so the apps can see it in their jail, and call it done. Obviously, the library would be signed.
Now comes the tough part. DLL hell. A WinSxS mechanism would be useful so apps that use different versions of a library would not conflict with each other.
Of course, the best solution would be filesystem level deduplication. If apps are stored encrypted on the device, then move to a dynamic library system and deduplicate the .so files.
This isn't the best solution, but it should significantly save space.
Silicon Valley (Score:2)
Transition period (Score:5, Interesting)
Re: (Score:1)
It is mostly Swift that is a pig, as it forces your app to ship with the ever-changing Swift libraries while the ObjC ones are stable.
This is hilarious, as Apple marketing is so powerful that in every WWDC presentation, the guy now have to say something good of swift (like : "you would not have this prolem in swift" when talking about optimizing ObjC), even if it makes little sense. Having such a big "swift apps are bloated" hanging all over the tech news is just too funny.
Re: (Score:2)
For some time now, on the x86 architecture, compilers did a better job with output code than all but the very best humans.
Re: (Score:2)
It sounds like they created their own DLL hell by requiring every app to have a copy of the library for compatibility reasons.
Of course, it wouldn't matter so much if they priced flash memory fairly and if they made the app download/install system clever enough to check if it already has a copy of that version of the library and use it.
Re: (Score:2)
Re: (Score:2)
It sounds like they created their own DLL hell by requiring every app to have a copy of the library for compatibility reasons.
Nope, they just wasted a lot of space. Probably the best way to solve it is with a filesystem with deduplication, because just bundling the libraries with the apps every time really does solve several problems. I've been playing with my Amiga 1200 lately and having to run around finding whatever.library is kind of annoying. It's orders of magnitude less annoying today than it was in the early days of the internet, but it's still a pain.
Of course, the other reasonable way is to add dependencies to app stores
Re: (Score:2)
Nope, they just wasted a lot of space. Probably the best way to solve it is with a filesystem with deduplication, because just bundling the libraries with the apps every time really does solve several problems.
Agreed; in fact Apple could take the deduplication idea even further since they have full control of both the App Store and the iOS device's filesystem -- Apple could maintain a database of secure hashcodes/checksums for every file in every app that has ever been uploaded to the App Store, so it could replace its download-the-whole-bundle install process with one that only downloads the files that the phone doesn't already have have stored locally, and (of course) only stores exactly one copy of each file,
App Thinning eliminates unused architectures (Score:2)
First Apple is moving to 64-bit for all iOS devices. Certainly there is some overhead maintaining both 32-bit and 64-bit frameworks.
The frameworks on the computer and compiled code are larger because of that, but the final version that goes out to the users device only includes the architecture they need it for.
Second, Apple seems to be phasing out Objective C in favor of Swift. As the article noted, Swift requires more space
The reason it requires more space is not so much the language itself, but that e
Re: (Score:2)
...but the final version that goes out to the users device only includes the architecture they need it for.
Did Apple ever figure out how this works with backup and restore? This feature was actually disabled shortly after its introduction. I am not aware that it has been reenabled.
It's been in there since iOS9 (Score:2)
App Thinning and Bitcode have been in place since iOS9 [imore.com], and have been on since then - not sure I ever saw that it was disabled? It's all certainly been active for a while now.
I've been able to compile using the bitcode option since then...
Re: (Score:2)
I did wonder about the difference between iOS and Android on this. We only recently ran an article talking about Facebook being 388MB. On my Android phone it weighs in at 162MB, and 10 seconds of Google "research" showed that universally apps are far larger on iOS.
so it was with desktops, so it will be with phones (Score:5, Insightful)
developers are building more and more complex things for them without considering the impact the size will have around the world,"
I cut my teeth programming computers with 1 KB of RAM (not 1 megabyte, not 1 gigabyte, but a mere 1024 bytes). On the plus side, you could lift it yourself.
You took every possible step to save a byte here, and 3 bytes there. Once desktop computers became monsters with megabytes and then gigabytes of memory, the need for that was reduced. Which is good in a lot of ways, but it also led to a generation of programmers who had no exposure to highly limited devices. They'd never written anything in assembly language, and they had only a dim awareness of the time vs space tradeoffs of the huge library routines they were using. This led inevitably to bloat, since out of sight is out of mind. I've seen people using many megabytes for something I'd do in bytes or kilobytes, but their approach required less developer understanding. It was amiable to programmers who didn't grow up bit twiddling, it was easy, and it was faster (for them) than trying to understand my way (which was fast for me, but depended on skills honed in another time). Programmer time is expensive, and most programmers have little low level knowledge about how the machine works under all the layers they depend on, so their approach allows people to accomplish things they never could otherwise. Is that good? Is that bad? Probably both, I think, depending on how you look at it.
The same thing is happening now with phones. Early phones were highly memory constrained devices, but now, that pressure is fading. Bloat is inevitable. It can't be stopped any more than the tide can be.
Re: (Score:2)
Not really an advantage... I can lift my smartphone just fine.
Re: (Score:2)
You say programmer's time is expensive, but I wonder how it compares to the full system-wide cost. I suspect that a massive amount of cost has been pushed to the unknowing consumer - possibly many times what the cost of better programming would be.
Is the combined time saved by modern sloppy programming practices greater or less than the cost of all of the extra memory required in billions of devices and the extra distribution costs for all of those apps. We don't consider things like, what is the energy cos
Re: (Score:2)
I suspect that a massive amount of cost has been pushed to the unknowing consumer - possibly many times what the cost of better programming would be.
Let's see...Swift takes more memory, users react by upgrading to iPhones w/more memory and more profit margins for Apple.
Older versions of Windows get slow and bloated with extensive patching, users react by getting new computers, boosting OEM license sales.
Conclusion: It cuts expense while simultaneously increasing sales. That's win-win!
Re: (Score:2)
Re: (Score:2)
If users developed a preference for buying smaller apps, you'd see smaller apps. It's not Apple's job to decide what you should have in phone apps (although they do a fair amount of it anyway).
Re: (Score:2)
You can cut your teeth all you want. The problem isn't the size constraints, it's the functionality constraints. I too do a lot of work on very constrained microcontrollers, but that doesn't mean I don't reach for a generic video library when I am working with a device that has a touchscreen interface.
If I re-invent the wheel every time I want to build a car all I'll ever end up with is a bunch of crappy wheels.
Re: (Score:2)
Re: (Score:2)
If it causes significant extra use of fossil fuel, then, yes, it's a bad thing for society. Individual user costs accrue to the user, and if an application is sufficiently annoying in some ways (like being a terabyte download) people simply won't buy it. It's a free market, and more successful businesses do a better job of matching their priorities to
System Architect? (Score:2)
The economic tradeoff (Score:4, Insightful)
An awful lot of that sounds like the bloat is due to the same things that are making pretty much all other modern software so bloated: economics.
Developer time has become much more expensive than hardware, so the entire industry has moved to development practices and tools intended to minimize the time required to create applications. But these productivity gains, almost universally, come at the cost of wasting bytes and machine cycles.
So all software has, for many years now, been getting fatter and slower, relying on faster hardware to make things tolerable.
Re: (Score:2)
Re: (Score:3)
I think we should stop calling such developers "lazy" and instead call them what they are: bad developers.
Re: (Score:2)
Re: (Score:2)
That would count as a conscious design decision, though, not laziness. Laziness is just taking the path of least resistance without considering the tradeoffs involved.
Re: (Score:2)
One of Larry Wall's Three Cardinal Virtues of programming. Lazy developers do things efficiently.
Programmers are adept at optimizing for what they're asked to optimize. As long as there's no money in reducing package size, developers will continue not to care about it.
Re: The economic tradeoff (Score:1)
Economics, yes, but you overlook a key aspect of the economics: it's cost shifting. Software companies push the cost of their inefficient software onto the consumer who must keep purchasing new, more capable phones just to be able to run pretty much the same crap he could have run on the old phone if the software weren't so sloppy.
Recursive library duplication (Score:5, Insightful)
I used to work at a game company. Before that, and coming from the a Linux world, I had always wondered how people manage to get even the executables to reach hundreds of megabytes to gigabytes. Now I understand.
For example, the game uses compression, so it embeds zlib. It also uses something like 50 externally or internally sourced libraries, many of which also embed zlib. Some of those embed other libraries, which again may embed zlib.
I found more than 80 copies of zlib in the game engine source code and its embedded dependencies. There were also tens of png and jpeg libraries, zip libraries and Lua interpreters. For building and tooling purposes only, there were around ten Python interpreters. Also, there were some eight copies of different versions of the in-house developed container library (STL replacement). And that doesn't count the libraries we didn't have source code for.
Nobody in our team even had the slightest idea that was the case. In the Windows world, that's standard and best practices. I believe this is largely due to the somewhat sorry state and limited benefits of dynamic linking on Windows.
The Linux world proves properly versioned dynamic linking can be extremely beneficial when done rigorously. To fix a security vulnerability in zlib, you only need to update zlib, not every application. Memory is saved: Any executable pages in dynamic libraries are only mapped once. That means you have one copy of zlib in memory per system, instead of 80 per application.
Statically embedding anything does have its benefits, though, which is why the commercial world likes it. It means you won't get to debug weird problems because of broken libraries on a system. Containerization is the trend also in devops, and that means explicitly duplicating stuff yo make it easier to maintain.
Re: (Score:2)
I'm just a humble amateur scientific programmer (I'm mainly a scientist), but I still have trouble understanding how "just" libraries can get anything into the GB range. In my humble number crunching code (linux based), it always seems to be large data arrays which end up eating up all the space. Could it be with phone apps that they're including lots of images which are what is principally eating up space?
Re: (Score:2)
Large data arrays are normally stored in data files, not in the executable.
Re: (Score:2)
This is a natural outcome of the "let's make methods and variables private to protect developers from each other" mindset.
Another reason is that (Score:2)
Re: (Score:2)
they test their apps on a relatively clean device
If this is the only sort of testing you do, then you aren't actually testing your application.
Which goes a long way to explaining why most apps are terrible.
Re: (Score:2)
While I was reading this I was thinking that the dev and testing environments should be hamstrung like a previous generation phone used by a teenager in terms of processing power and hard drive space. It would suck to develop under that, but it would mean that on a next generation phone the app would be small, fast, and responsive.
Re: (Score:2)
My wife had to argue with her boss for some time to get a limited account on her computer. She had found too many times in which she'd written something and it worked just fine, but required some admin privilege she missed, and so it wouldn't work for the users.
Deep Learning Model Weights Are Big (Score:1)
Re: (Score:2)
I'm not aware of any apps I use that involve machine learning. Probably because I make sure that my machines cannot talk to the cloud.
It's the law of nature (Score:3)
As in nature, the more powerful grow bigger as to kill off the competition for food and space.
By making my apps larger than required, it means there is less space for other apps on the phone. If room is at a premium, then you're less likely to load duplicate functionality (While it's nice to have two weather apps to get an average, if I don't have enough space, I'll just stick to the one).
This can backfire as people may instead delete the one big app to make room for two smaller but possibly just as competent. However, since file sizes are not always quickly available, more likely people are too lazy to do the research.
It's simple (Score:3)
Apps are getting bigger because iOS devices are more powerful
The only explanation needed is the old adage, which I have never found to be untrue:
"Software is a gas; it expands to fill its container."
Re: (Score:2)
Cargo cult programming? (Score:2)
Airplane reference (Score:2)
https://www.youtube.com/watch?... [youtube.com]
Feature Bloat (Score:2)
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
- Antoine de Saint-Exupery
DUH (Score:2)
Apple could fix this (Score:2)
Apple could fix with with a "tax" on large apps. Larger apps have to have a higher price share with Apple. Free apps have to pay say a cent per every 10 MB over a certain size. That would make everyone's code tighter quickly!
This is inevitable (Score:2)
My $225 LG Stylo 3 (Score:2)
Bulky applications or DLL hell (Score:2)
The more things change, the more they stay the same.
Graphics bloat? (Score:2)
Does anyone have any info on the amount of bloat the is actually embedded graphics information? I have no direct data but from the apps I see the big ones always has a lot of still-frame and full-motion video component embedded in it. Almost always games and entertainment, not business or utilities.
It's not just IOS (Score:1)
Android development has also suffered the same issues. Showing my age... In the old days I remember trying to optimise some code and data to fit into 1K of RAM. It wasn't an easy task but eventually you'd work out a better more reusable function to serve more than one purpose and nail it.
<rant level="maybe"> Now days it seems that just getting something running is good enough to put into production. Agile projects run by PMs that think that teams working separately in little groups with no interac
ABI support coming in 2018 (Score:2)
Do you suffer from app bloat? (Score:2)
Headers (Score:2)
Seems to me that history is repeating itself (Score:2)
http://seriss.com/people/erco/... [seriss.com]
This is mandatory reading for every new IT employee in my company.