In the western world there are two main app stores, Apple's App Store and Android's Google Play Store. Here are the lessons I've learned over the years about working with those store dashboards.
Over the last four years I have worked as designer and product manager for several game developer who self-publish their mobile games. In each role, I had the responsibility for maintaining apps and their respective storefronts using their developer consoles on iTunesConnect and the Google Play Developer Console. Each system has given me it's fair share of frustrations, and I want to share the lessons learned and some best practises you can use to streamline your app publishing. So, in no particular order:
Whether the app is a Paid app with an upfront fee, or an IAP (In App Purchase) supported game, all three stores give developers some degree of control over their prices.
Highly recommended: make your In App Purchases and decide your App Price on iTunesConnect before Google Play.
iTunesConnect has developers to choose a price 'tier' from their matrix, allowing Apple to maintain a (mostly) consistent price across all territories. It means they have control to raise or lower prices in response to currency fluctuations or changes in legislation, such as the new EU tax rules. This means that for paid apps, developers can only have one worldwide price active at a time, unless you have the same app under different IDs for different territories. It limits developers from lowering the price in certain territories, such as for local events or because sales are low in a territory.
The iTunes Price Matrix is a densely packed mess, but it makes it very easy to adjust prices for sales
This becomes a practical issue for territories such as China, where users are less likely to spend as much on a paid app as in the US or Europe. For In-App Purchases however, developers can get around this issue by having unique IAPs for different territories and showing the correct ones in-game. Therefore, the same package would be uploaded twice at two different price points, visible in two different territories. It's complicated, but you can sell your basic hard currency package for 2.99USD in the USA, and 0.99USD in Turkey, for example.
App Bundles
iOS developers can now bundle their apps together and sell them as a package, which I really like the idea of but have never tried myself. However, you cannot bundle IAP content in, such as additional episodes. If you want to add all the episodes from your game into a bundle, they need to be distinct apps and bundled together. If you want to stick with IAP episodes, your users will need to buy (or download for free, your choice) episode 1 and then buy an IAP of the remaining episodes together.
There's another problem for indie developers. If you and some other developers want to bundle your games together, much like a Humble Bundle, then you need to transfer ownership of your game from yourself to whichever developer is creating the bundle. You cannot just have a few developers agree to opt-in to a bundle and split the profits, which I think is a real missed opportunity for Apple.
Google Play gives developers complete freedom to choose their own price per territory. To help you out, the system allows you to give an IAP (or Price Template, more on that below) a default price in your standard currency and it can convert to local currencies for you. This also means they can give you the option to round these generated prices up or down according to local custom (everything ends in .99 in the UK, for example). Once the automated conversion is done, you have the option to go through and change them to whatever you see fit. Above, I talked about using two identical versions of the same purchase to give different prices in different territories (that's just confusing, right?). In Google Play, you can skip that whole problem and just give each country a different price if you want. So Google Play is much friendlier to use in this regard.
This flexibility also causes some problems. It makes temporarily discounting items difficult to manage since the prices are not saved and you can't plan an IAP sale period and revert to the previous price automatically. All the prices must be manually updated every time a discount period begins or ends. With its price tiers, this is very simple on iTunesConnect, and they give you the ability to plan several tier changes to enable on future dates. Since there is no straying from the pricing matrix, there are no unique prices to save and restore.
One very important note. Google Play let's you determine if an IAP cost includes tax or not. As far as I can tell, if you don't include tax then the user will pay more than you think they are. This ruins any attempts at price parity if you want to go for that. So I always include tax.
In order to improve, Google Play implemented "Pricing Templates." This handy little godsend allows developers to set up a template with the correct prices for territories and apply it to multiple products and IAPs at once, removing the need to input prices manually if two items are the same price. So if you have an IAP with 50 Diamonds in it, and an equivalently priced IAP with 5000 Gold, you can give them the exact same price without having to do all the work twice. Below, you can see how I set up the templates to match the iOS Price Tiers.
I invested a lot of time setting up these tiers, but I now save so much time when repricing items and adapting to iOS App Store tier changes.
By matching the App Store tiers, you have price parity for your app across both platforms so your Android players aren't paying more or less than those on iOS. Each IAP or premium app is assigned to a Price Template. New apps and new purchases can now have the same prices without any additional work. When Apple updates their price tiers, you can then make the changes in one place on Google Play to affect multiple purchases. It's a great improvement for Google, though I do wish they would import prices directly from Apple for those who choose parity.
Bulk Import
Google Play allows you to create a CSV to bulk import IAPs. However, it takes a lot of work to set up the CSV correctly and you still have to manually check through and upload images. Unless you're uploading more than 50 purchases, it's not worth the time or effort repeatedly trying to get the format right. Take a day or two to do it manually and do it right. I would also never use bulk upload to modify existing purchases, it's just a nightmare.
Apps on both stores are presented in a number of ways. Typically, there will be an app description, gameplay screenshots/promotional images and a video. The description is written by developers to broadcast the unique features and general information about the game. It is a great opportunity for convince potential players to download.
The screenshots are more problematic since each platform has distinct screen aspect ratios and pixel sizes and they (supposedly, but you can somewhat get around it) require images for each. For instance, an iOS app releasing on iPhone 4 and iPad requires the screenshots dedicated for those devices. When you take into account that the iPhone 1 - 4S, iPhone 5+ and iPads have distinct aspect ratios, the amount of work quickly escalates taking much more time to produce and upload.
Google Play is a little easier in this regard. It asks for screenshots for 7-inch, 10-inch and phone, but you can upload the same images for each, saving you a lot of time. You can even upload images produced for iOS to save even more time!
The biggest amount of work is with localised screenshots. If you have text in your images that you want translated into multiple languages, the amount of images is multiplied by the amount of device types and again by the number of languages. It's a lot of work.
This app has localised store images. Google makes it easy to drag images in, but with 16 languages it still takes time and manual labour.
Uploading a video means encountering similar issues. Google links to a video from YouTube whereas iTunesConnect requires a video to be exported in each aspect ratio and uploaded to their system individually. As you can imagine, this multiplies the amount of time required to prepare the App Store in comparison to the relatively easier Google Play.
Each store allows the developer to create achievements that are triggered by their app. The amount of achievements and the points they can distribute are limited by each store, providing a consistent experience for developers across both platforms (it looks like these limits are based on Xbox Live's limit to 3rd party games of 1000 points per game in total). Much like Xbox Live, when the player performs an action or reaches a developer designed goal, the achievement is unlocked.
iOS allows achievements to carry two descriptions, one for before they are unlocked and another for after, which is a feature missing from Google Play. However, Google Play handles text translations much better than iOS, allowing developers to just tab through languages adding the localized description and icon. iTunesConnect forces you to open popups and move between pages just to add a new language. It adds on a few steps that makes the entire process longer and more convoluted than it needs to be.
iTunesConnect has a lot of popups to go through, but you can add pre-earned and earned descriptions to your achievements so you can hint what they are about without giving them away.
Google's interface is much simpler and faster, and this is the same anywhere else on the dashboards that you need to localise, such as the store description.
Leaderboards follow much the same format on both dashboard. The only distinction is that Google Play allows the developer to keep track of how many scores are posted to the leaderboard. If iTunesConnect has a way of making this visible I haven't found it yet.
Make your Achievements and Leaderboards on Google Play first. It gives you IDs that you need to use. iTunesConnect let's you set your own ID, so you may as well reuse the ID from Google Play and simplify the task.
Both store dashboards allow you to prepare your next release ahead of time. You can upload new versions of the app and write in a changelog to tell your players what's new. On iTunesConnect, you can also prepare new screenshots and a new app descriptions, but it seems on Google Play you cannot do this ahead of time.
So that's it for now, these are just some of the features I have used most when delivering apps. There are plenty more features, such as app analytics on both dashboards and Google's other features such as built-in marketing, A/B testing of the store page and Quests, but I can't comment on these with any real authority. Apple has a Mac App called App Uploader which is a client-side version of iTunesConnect. It can speed some things up by allowing CSV bulk upload of Achievements, but I've found little real use for it in the time I tried it.
In order to wrap this up, I want to leave you with some brief tips and tricks that I've found really helped me once I learned them:
Tips and Tricks
Create your Achievements and Leaderboards on Google Play first. Google creates unique IDs you need to use, whereas iTunesConnect allows you to paste those same IDs in. This helps your programmers a little bit and saves potential bugs where the wrong ID goes to the wrong store.
Determine your app and IAP prices on iTunesConnect first. iTunes is inflexible, you can only charge in their pre-determined price tiers, but you can then use these prices in other stores for platform parity.
Use the Pricing Templates on Google Play to make Android versions of the iOS Matrix tiers you're using. Even if you think you're only going to have 1 IAP in a price tier, create the template for that tier and apply it to that IAP. You really, really, don't want to have to go through all your in-app purchases every time there's an update to make changes. This way, you change in one place only.
Even though iTunesConnect says they can review an app in 24 hours, plan for a week to submit your updates and two weeks for your initial submission. You need to account for failing review and resubmitting, and adding the goddamn iOS certificates.
As with everything in mobile, start small, test, then expand. Make a couple of IAPs, test they work in your app, then add the rest. You'll find small, easy to fix issues early on with a small number of items to repair rather than having to repair many later.
These are lessons I've learned (often painfully) over the last few years. If you have any questions about anything discussed here or anything else, feel free to contact me on Twitter @DarylHornsby or email me at daryl[at]darylh.com. I'm friendly and I love to help out where I can!
This post originally appeared on my blog darylh.com. You can find more articles about Free-To-Play games and games in general there.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
