Fair Warning: this week’s post is going to be pretty technical and will talk directly to developers. The post assumes that the reader has created their own project in Xcode, or at least knows how to build a project in Xcode and knows what the results of the build process are.
Should you be worried that I know exactly what your bundle contains? Does it bother you that I can use your files directly without your knowledge? How about this one: would you be ok with me taking your files and creating a clone of your app? This might come as a surprise to you, but unless you do something about it, there is nothing stopping someone from doing all of these things to your app. TODAY!
As I’m sure you all know by now, app bundles are shipped as a .ipa file. This is just a .zip file that’s renamed to .ipa as part of Apple’s process for iOS development. In simple terms, when you add a resource file to your Xcode project, it automatically gets included in the bundle (as you would expect). Some developers make the effort to organize their bundles into subfolders; say a folder for audio, which might have its own subfolders for music and sound effects. Another example might be graphic files split up into characters or locations or whatever.
Other developers don’t seem to care about a file tree and put everything into the root folder of their bundle. There is no real “right” way to organize your bundle contents; I suppose you should use whatever level of organization and complexity you’re comfortable with. (My personal preference is to organize the bundle so that the root folder is tidy. I’ll talk more about this in a future post, but for now I’ll leave it at that.)
The contents of your bundle, that is, the actual files your app needs in order to run properly, is really what I want to talk about this week.
The files your app needs is obviously dependent on the kind of app you’re creating. Games, for example, usually have several different kinds of files: graphics, audio, level data, and so on. (It’s more convenient for me to talk about games, but the principles apply to virtually any iOS app.)
Graphics are usually .png or .jpg. Audio files can be anything from .wav to .m4a to .mp3. Level data is usually something along the lines of a .xml file. I’m not suggesting that these are the only kinds of files you can have, I’m just sighting some examples.
The Content Problem
All of this sounds like pretty standard stuff right? If you need some graphics, more often than not you’ll use a .png (or several of them). Need some audio? No problem, just use a few .m4a files. The problem with this is that all of your files can be viewed offline by anyone whenever they want to. Sure, there is a build setting to compress PNG files (and I’m not sure if this causes them to be not-immediately viewable or not, can anyone shed some light on that?) but that’s not enough to stop someone from viewing them. Don’t believe me? Take a look at my first post about the Wired app. I pulled the various flavors of the front cover directly from the bundle; those aren’t screen grabs or doctored or modified in any way. Pretty scary!
Take .xml files as another example. That’s a human-readable format; it’s just a text file. Anyone who looks can see how your data is structured.
It boils down to this thought: if you have created a proprietary game (or engine or app) wouldn’t you want to keep it proprietary? If the thought of someone like me (a developer, or, to put it bluntly, your competition) waltzing through your data at-will makes you uncomfortable, there are some things you can do to prevent preying eyes looking through your stuff.
One thing you can do is to not use ‘open’ formats and create your own. This takes time to get up and running properly because you have to spend time up front to create a converter and then a loader/parser. One of the benefits to creating your own format is that you are in complete control of it and you can change it as often as you need to, whenever you need to, instead of relying on someone else to make the changes you request. The other side of that coin is that the author of the open conversion tool you’re using could change something out from under you, forcing you to either live with using an older version, side-stepping any issues caused by upgrading the tool, or spending time finding another tool.
Another thing you can do is to compress your files. Granted, .png files are already compressed, but the idea here is to obscure the data. Compressing has the added benefit of making your bundle size smaller once it’s installed. (The download size difference is probably negligible because the bundle is already a .zip file.)
Taking the compressed files idea even further, you can group your compressed files together in a bigger file. This makes it more difficult for people to view them properly because they now have to somehow separate and extract the files. They can’t do that until they analyze the group to see what it contains.
For .xml files, you can ‘bin-ize’ them, that is, you can use a tool to convert the (very large) text files into binary representations. Various tools exist to do this, such as xml2bin (I’m sure there are others), or you can create your own if you can afford to spend the time. One thing worth mentioning here is that if your .xml files are complex, such as leaves are derived from other leaves, I’m not sure how binary converters handle that. We don’t use .xml files (for various reasons, some are talked about in this post) so I don’t know how easy or hard the binary conversion process is. I’m just stating here that options do exist for converting text-based .xml files into something more difficult to read/analyze.
Hopefully I have piqued your interest in wanting to hide your data. The thought of someone seeing how I have implemented something, or even worse, them using my content in their own app is a big concern for me, so I make it really tough for inquisitive eyes to figure out what I’m doing. If you want an example, I invite you to download 30/30. It’s free and you can see how I handled the data hiding issue.