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."
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.
I think the issue is redundant code through duplication, not code that isn't used.
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.
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.
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.