Slashdot Mirror
Developers Explain Why iOS Apps Are Getting Bulkier (ndtv.com)
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."
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."
Doesn't it prune unreachable code?
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.
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?
Dynamic link libraries.
Tim Cook should talk to this guy named Bill Gates, he might know a bit about them.
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.
> The high-resolution image assets that developers are required to add also contributes to the size of an app. -- This. Having to provide icons at 57x57 and 58x58, just for two examples out of dozens, is asinine. Our app code is dwarfed by the image collection size just to provide the minimum number of icons and load screens required.
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.
I'm pretty sure the app developers are just renting out storage space on the user's phone.
I wonder how much of the code bloat is also due to multiple transitions happening at once. First Apple is moving to 64-bit for all iOS devices. Certainly there is some overhead maintaining both 32-bit and 64-bit frameworks. Second, Apple seems to be phasing out Objective C in favor of Swift. As the article noted, Swift requires more space but I wonder how much of the space is because both are used.
Well, there's spam egg sausage and spam, that's not got much spam in it.
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.
Isn't the role of architects to ensure independently developed components have access to shared resources? [sarcasm font]Oh wait, architects aren't needed when you can just hire more coders. [/sarcasm font] Seriously though, how many times you have heard we don't need architects?
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
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.
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.
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.
A lot of developers develop their apps in a vacuum, e.g. they test their apps on a relatively clean device which doesn't have any other apps installed aside from the OS itself. It's easy to see why they don't really care how much space their apps occupy.
No one mentioned what is probably one of the biggest reasons for bloat from the apps of the big tech firms over the last 10 years: Machine Learning Models using Deep Learning. If machine learning models are included with the app as opposed to the cloud it will add up. Even the most compressed of these models comes in at 10-30 MB. Add one for photos, one for search, one for voice, and one for some other as application specific model. At this point you're already pushing up to ~100MB right there and you haven't even started writing your program or including any images! This is done for several possible reasons such as quicker response time or so things keep working without an internet connection.
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.
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."
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 every app has to ship the Swift framework inside of it - when they reach ABI stability, it will mean you can use the Swift that is included in the system (just once per Swift version) instead of having to include it in the app. But it may be some time before that is complete, they are now talking about what Swift 5 will haveand it's working on one of two major aspects for ABI compatibility...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If so, is it on Apple's end, or the developers' end?
There is no XUL, only WebExtensions...
https://www.youtube.com/watch?...
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
In a bit of shameless internet panhandling, I accept Litecoin Donations at Lbd2oH9QsthD1GfuUXPyka12YxvWJYnBVf
No incentive to slim down the code. Same with PC's. With space NOT at a premium, why waste the time trying to slim down the code. Plus, people want/demand/expect more things from the application.
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!
App Thinning and Bitcode have been in place since iOS9, 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...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is a small illustration of what is happening in all things, not just technology, the continuous, unrelenting, addition of complexity. At some time there must be a "complexity collapse."
E Proelio Veritas.
has 32gig of storage built in and supports a 2 terabyte SD card. This doesn't seem like a software problem, this seems more like an "Apple charges too much for storage" problem. When Sony tried this on the Vita it cost them a ton of sales.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
The more things change, the more they stay the same.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
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 interaction between them is a good thing, and that "good enough" is good enough and done, are also to blame. As is the countless untrained and inexperienced developers working as Solution Analysts, Team Leads and Senior Developers because the company doesn't want to pay for experience and quantity not quality dominates the financials. </rant>
When shit hits the fan get some of these https://youtu.be/pY-GncsZ-UE
> On the plus side, you could lift it yourself.
:-) But I guess you mean an advantage compared to ENIAC and its kin... the 1/2k machines or the even heavier 1/4k machines. Come to think of it, the original bit must've really massive!
Not really an advantage... I can lift my smartphone just fine.
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 cost for downloads? If 80% of that is bloat that could be removed, what does that mean in terms of internet infrastructure. These apps often download full new copies every month. Is it a significant portion of traffic? Does it push us to putting in new fibers or rushing 5G?
I'd like to see a full analysis of the system-wide cost of app size.
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.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Good news. ABI support coming to Swift in 2018 https://www.theregister.co.uk/...
It could be stopped if Apple stopped approving apps that were grossly oversized for what they were.
There's an app for that!
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
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.
It's why I prefer header only libraries.
Those who do not learn from commit history are doomed to regress it.
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!
here is a memo that circulated in SGI in 1993, about how IRIX got bloated and unusable because of exact same reasons as mentioned in the original post:
http://seriss.com/people/erco/...
This is mandatory reading for every new IT employee in my company.
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).
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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 the users' priorities.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I'm optimistic about all of these retro implementations of legacy computing platforms. I think that any programming curriculum should involve some exposure to a modern implementation of an Apple //e, for example. That would teach frugality and perspective.
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman