The Apps are Too Damn Big

I have a feeling that Apple might just start to run into the kinds of realities MS and others have been living with for years. Either they choose to piss off millions of users of older devices or figure out how to allow for evolution without causing problems for the installed base. Or, maybe they don't.

As an iDevice user I am glad that I chose to buy all my devices with the absolute max storage available. Everything I have has 64GB. So, we are good for a little bit.

As a developer I cringe at the situation. I am currently working on an app that has about 400 graphics files that will ship with the app. If you do it their way you have to produce each one of these files in four different resolutions. This means that the image directory is now huge. It is three times larger than a scenario where we would have app bundles customized for each device.

In looking at the problem we decided to do the following. All of our files are produced at what would be @2X resolution but are named without the @2X. We are going to ship the app with just 400 files at a single resolution instead of 1600 files at four different resolutions. In the end, if you do the math, your app bundle will be significantly smaller due to the significant reduction in size of the images directory.

As far as performance is concerned, the images work very well all they way back to iPod touch v2.0 devices. No issues there. So, that's the plan.

Maybe what Apple is pushing all of us towards is a scenario where we are forced to detect device type and capabilities and load resources accordingly on app first run. Think about this for a moment. Now their servers don't have to push out so much content and you will have to foot the bill for your free graphics-intensive app getting three million downloads. I could be off base here. But, I just don't see a way to deal with this unless you are willing to ship your app with thousands of files, most of which will never be used by the device the app is installed on.

I also think it's high time that apple put out an iDevice with the ability to expand memory capacity in the field. I know, I know, they want to control it all. They are big enough to have custom Flash chips made with all the encryption they want so people can't move the flash chips from phone to phone and steal software.

Happy coding.

The comments I see are about technical solutions. I think Apple's happy that there's finally a reason for people without humongous music collections to pay $200 for 64MB of flash memory.

I have something like 400 apps. They total around 20 gb with the median app being 20 mb. This is more like the difference between 95 and 100 apps. If having a lot of app storage is your deal breaker presumably you didn't buy the device with the least storage making it a small issue.

This dilemma isn't limited to iOS, or mobile apps. It's all user-facing software. Everything that ships to users these days -- traditional desktop software, web apps, even static blogs -- is much larger than it needs to be to achieve its functionality.

This isn't necessarily a bad thing. There's a huge tradeoff between size of the product and development speed. We've switched to a pattern of bundling lots and lots of large libraries with everything we ship, and tons of static resources, and tons of translations, and on and on. And it makes everything huge.

But it means you "full-stack engineers" can knock out full-featured, money-making web apps in hours/days/weeks instead of weeks/months/years. Most of the "look at the monetized product I wrote this weekend!" posts that show up on HN could be a fraction of their size, but would have taken much longer to develop.

The link is specifically complaining about resource files, which are probably easier to manage than libraries, but it's still probably not worth the effort for Apple. By making it as simple as possible, developers don't waste any time worrying about how they are going to structure resource usage for their app. Just throw everything in there and get on with it.

At work, I develop for platforms with My side projects are in horribly wasteful monstrosities like Python and Objective-C/Foundation because, in my spare time, I like projects to actually get finished... to hell with binary size.

I don't understand why "universal binaries" exist at all on iOS. On desktops where the app space is more "free" it has a purpose, but it's not like users are regularly moving apps from one iDevice to another -- so what on earth is the point of having three different things altogether? The much more intelligent solution would have been to simply allow developers to upload 3 different binaries, but only present it as one on the app store. Then the app store correctly downloads the correct one depending on your device (iTunes can keep all three if it wants or whatever), and then there is no need for the app store to muck around in your app internals or anything.