For a long time now, I have been thinking about what developers can do to reduce their app’s size. I’m not talking about the easy and obvious stuff like file merging and data compression, though we’ll talk about that in a future post. I’m talking about the extra steps developers can take that would really make a difference in their app’s download size.
App bundles are just zip files so the contents of the bundle are compressed, but that only gets you so far. You have to take extra measures in order to get the smallest possible download size. Here’s something you might not have considered:
Get Clever About Localization
There is a game in the App Store called Jules Verne’s Secrets Of The Mysterious Island. It was released in late 2009 and it weighs in at a whopping 738.2MB. (Yeah, that’s big! About 150% bigger than the Wired app that started this blog.)
What’s in there that’s so big? Well, I did a little digging and it turns out that most of the bundle size is consumed by 3d files (432MB worth to be precise). The next largest set of data is localized files. That is, files existing specifically to implement English, French, German and so on.
The game supports the “Big 5” languages: English, French, Italian, German and Spanish (a.k.a. EFIGS). This is great! I fully support applications that are translated to other languages. However, all of the non-English files consume a lot of space: 170MB.
The Problem With Localization
If a customer is English, only ever runs apps in English, and has no intention of setting their device to anything but English, is it fair to include all of that extra localization baggage? I don’t think it is. But as a developer, how do you support EFIGS and still have a small footprint?
Well, you can employ a trick we used in the early days of traditional mobile apps. Early handsets had a hard-and-fast rule where your app bundle can only be a certain size and no more (some J2ME handsets had a maximum bundle size of just 64K!) What we did to get around that was a little sneaky: ship only the bare minimum in your bundle, and when the app is run for the very first time you download the rest of the data and only for the language the phone is set to.
The amount of data we’re now creating and talking about in the new mobile space is much, much larger, so doing this has some obvious pros and cons associated with it: what do you do if the device doesn’t have a net connection when it’s run for the first time? Will the costumer allow you to impose a potentially long delay? And so on. Your mileage will vary of course so you have to consider the options carefully.
The Trade-Offs
So what do you think? Will the customer let you download lots of data? You could launch with enough data to get into the app a bit and then download the rest of the data in increments. You could download the data in the background and only make it know when the lack of data becomes a roadblock.