How To Indie – Publishing Your Mobile Game for the First Time

If you have been following the “How to Indie” blog so far, you will have now built a game on your own without spending any money, manipulated your target audience into a salivating frenzy with your formidable marketing campaign, and basked in my infinite wisdom as to why no one should ever support freemium. Hopefully, you’ll have bought a few of my games too!

Unlike last week, this post is another instructional post. It’s a list of the common things to watch out for when publishing your first game across multiple mobile platforms. In my experience, if you know all of the quirks and limitations from the start, you can design your game around them, and generally have a smoother submission process. As with other posts on this blog, some of the details are specific to the Unity engine.

Submission time frames (All platforms):

If your marketing plan relies on a simultaneous release across all platforms, then you will need to take the submission times into account. For example, submitting to the App Store takes between seven and ten working days. Google Play can submit within around five hours. Submission to the Windows Phone store can take between two and seven hours. The Amazon store can complete a submission in around ninety minutes.

Supporting the “back” button (Windows Phone & Android):

If you’re writing for Windows Phone, then you need to support the back button, or you will fail submission. From the title screen, the back button should quit the game on Windows Phone. From any other screen, it should work as a “cancel” button, taking you to the previous menu screen. Strictly speaking, Android apps have the same requirement, but it’s not as rigidly enforced.

In Unity, you can support the back button like this:

if(Input.GetKeyDown(KeyCode.Escape))
{
// Do stuff
}

Windows Phone 8 vs Windows 8 vs Windows 8 tablets:

This isn’t obvious in any documentation that I’ve seen, so I’m writing it here. If you compile an app for Windows Phone 8, it will not work on Windows 8 tablets. Windows 8 PCs and tablets use the same programs, both of which are downloaded from the Windows 8 Store. Therefore, if you want to support Windows 8 tablets, you will also need to support Windows 8 PCs. This can become a limiting factor in terms of game design. Simultaneously supporting touch screens and mouse clicks is easy enough, but PC’s don’t have accelerometers, making any games with tilt controls difficult to support on a Windows 8 tablet.

Snapped view (Windows 8 only):

This is a feature that any Windows 8 PC/tablet apps must support. Basically, the user can flip the screen from portrait to landscape mode and vice versa, at any time (unlike iOS and Android, you cannot lock the screen to one orientation). Moreover, the app can be dragged out of focus and re-sized to fit any arbitrary portion of the screen. The result is that developers have to support any resolution at any moment during gameplay. The standard workaround for this is to display a pause screen whenever the resolution changes.

GUI textures (Unity only):

Writing from experience, I’ve found it best to never use these when developing for multiple mobile platforms, because the screen resolutions for different mobile formats are inconsistent. In the case of Apple, they are inconsistent between devices. The difference in resolution can be enormous (the iPad runs in a 4:3 aspect ratio, while most Android devices are 720p, while Windows 8 needs to support arbitrary resolutions that can change during gameplay). Unity’s GUI Texture workflow will scale and re-position elements to an extent, but not to any quality that is shippable (for example, you may see squashed GUI textures on iPad, joystick buttons may appear too large on Windows Phone, GUI elements may disappear off the screen on Windows 8 tablets etc). My favoured workaround for this is to either detect and support changes in the resolution via an Update thread, or to build the GUI in 3D space using TextMesh assets.

The 50MB file size limit (Android only):

If you are creating a graphically-intensive app, or if you are storing your music as wav files instead of mp3, then you will find this limit on file size. Strictly speaking, Google Play will not accept an app of more than 50MB in size. However, Google Play supports “expansion files”, that allow you to export larger apps in separated pieces. Unity’s publishing settings include a checkbox labelled “Split Application Binary” that enables this, by creating a small apk file using your first scene, and storing the rest as expansion files in obb format.

NOTE: At the time of writing, there is a bug in Google Play’s submission process. To upload an expansion file, you must select the “switch to advanced mode” option in Google Play, but this option doesn’t work until after you have published your app. The standard workaround is to upload your app (without the expansion file), publish it, then upload a new version of your app (along with the expansion file) as an update.

The 100MB file size limit (iOS only):

iOS has a similar limitation to Android in this regard. iOS can support binaries of more than 100MB in size, but stipulates that your consumers must download large apps via Wi-fi (this can have a negative impact if you are relying on impulse purchases to drive your sales). It is worth noting that submission to the App Store adds around 7MB to your overall file size.

Texture compression quality for iOS vs Android (Unity only):

Your textures will look different when you compile your app in Unity for iOS and Android, because texture compression is handled differently on the two platforms. Android palletises your textures (everything drops to 256 colours with no dithering). Whereas iOS maintains the colour depth, but introduces blocky compression artifacts to your textures. For most cases, this is fine, but the compression can look horrific on GUI elements and sky-boxes. Unity allows you to define textures as “uncompressed” per platform, completely removing any compression glitches. However, uncompressed textures add to your file size and your load times, and have a minimal impact on performance.

Fog for Windows Phone (Unity only):

Fog is not supported by the Unity engine for Windows Phone. If you are releasing on multiple platforms (including Windows Phone), you will need to add this custom code to your shaders to emulate the effect of fog. From my own experience, this custom fog shader code does not appear to affect performance.

Have marketing materials ready before you submit (all platforms):

The various app stores require screenshots, icons, videos, and promo images of various sizes. Having these ready before you submit your app will make the entire experience less stressful! As a rule, it is best to provide these images in PNG format. Some of the stores support JPG for some of the files, but the PNG format is supported universally across all the stores (making everything in PNG means that you have one less thing to remember!).

iOS: 1024 x 1024 (NOTE: Don’t use transparency on iOS icons. Not every page on the App Store supports 8 bit alpha consistently. Sometimes you’ll get a black background, sometimes you’ll get a white background, sometimes the transparency will be dithered to 1bit alpha, etc)

Kindle: 114 x 114

Promo graphics are expected at these resolutions:

Android: 180 x 120, 1024 x 500

Kindle: 1024 x 500

Windows Phone: 1024 x 768

Windows 8: 414 x 468, 414 x 180, 558 x 756, 558 x 558, 846 x 468

iOS: 358 x 358, 1000 x 800, 358 x 173

Pay Thresholds (iOS and Windows Phone):

Finally, when you begin to actually sell your apps on the stores, be aware that you will not be paid until your apps have collectively sold above a certain threshold. The threshold for iOS is $150, Windows Phone is $200, and Android has no threshold at all. It is very likely that for iOS and Windows, you will be working for free until you have around three or four of published apps to your name (or one very successful app!).