For a long time now, I have been thinking about what developers can do to reduce their app’s size. (The domain name for this blog might be a hint to that, but my obsession started a long ago.) 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.
What are some other not-immediately obvious ways you can reduce the download size?
I’m a bit late to the show. But the question is: what makes the i18n data that large?
What normally changes for each language is the texts, not the images. So the package get’s large when you pre-render texts into images for buttons, HUD or other in-game / in-app stuff. The solution to this problem is: don’t pre-render but render the texts in the app. It is sometimes impossible if you have some fancy texts in fancy images but most of the time it is possible with Core Graphics.
If you do this, each language pack is only some strings files and maybe XIBs.
Hi Christian…
Better late than never! :)
I agree with you. Generally speaking, not ‘baking-in’ language specifics to assets is definitely the way to get a smaller download size.
If I remember correctly, SotMI is so large because there is lots of voice-overs that are localized. You can’t really do much about this other than gritting your teeth and using an audio format that gives you the smallest size per file, perhaps even mixing formats to yield a better return.