Ways To Make Money With Unity Apps

Ways To Make Money With Unity Apps

Here’s my next post which appeared first on Simple Programmer.

So you’ve got an idea for an app, but you want to actually profit from this idea, not just pour a lot of time, effort, and money into something that won’t give you a return on investment.

In the 10 years since the App Store first opened, the number of ways to make money from an app has grown from the single option of just selling your app on the store.

Unity has made creating apps for the Apple App Store and Google Play extremely easy with its Unity editor and tools. You only need to create one codebase to distribute to all the stores. And they have even developed services to allow for extending your apps and adding additional streams of revenue into the project even easier.

But, which stream is right for you and your app? And does its potential revenue align with your monetary targets, business goals, and development skills? Would a monetization method that’s more costly and requires more development effort be a better option in the long term if it makes you more money?

This discussion of the typical ways that developers generate money from their Unity apps will help you answer these questions.

Monetization Methods

There are many methods to monetize your Unity app. However I’ll be discussing those that are well-known:

  • Full price
  • Unity IAP
  • Freemium
  • Unity Ads
  • Unity Asset Store

Sell Your App at Full Price

When the App Store first launched in July 2008, the only way to monetize your app was to sell it at the full price.

In 2008 there were only approximately 23k apps and games within the Apple App Store, compared to the approximately 2.2 million combined apps and games in 2018.

The revenue potential in those early days was significantly higher. Small, short, and simple apps selling for $1.99 were netting the developer enough to let them give up their day job. This was because the competition and market was small, and the user base was a lot less sophisticated regarding the quality content of their apps.

Full-price business models are still the easiest to set up and predict sales from your apps. The revenue you generate is 70 percent of the full price of your app due to Apple’s and Google Play’s cut (this doesn’t include any currency conversion charges). With this in mind, you can roughly calculate that the total price of the number of apps that are downloaded correlates 10:7 with the amount of revenue you will generate.

If you want to set this up for your Unity app, you don’t need to do anything specific. Simply create your build, and then upload to the appropriate app store, and set the price to whatever you wish.

Unity IAP

In 2011, In-App Purchases (IAP) were introduced. These items could be small, like cosmetic upgrades, or big, like the ability unblock the full version of your app.

Along with the size of the IAP you can offer, there are currently three different types of IAP:

  • Consumable
  • Non-Consumable
  • Subscription

Consumable items are those that are reduced by one when used. They can only be used a set number of times (this is usually once). For example, the jelly fish used in Candy Crush Saga by King is consumable. Non-consumable items can be used multiple times. An example is an upgrade to your character’s armour. Once purchased, the character will use it all the time. Subscription items are those where the user will be charged a set amount per month, year, or any frequency that is set by the developer. The subscription option was first introduced in 2016. For example, getting access every month to all updates and all content unlocked in an app is done by subscription.

Unity IAP requires a bit more development effort to set up, but it means that you remove the cap on the revenue you can generate from any one app you create. By adding in IAPs, you won’t just be limited to earn a single amount for an app sale in the app store; instead, you could earn multiple times, depending on how many IAPs you set up and how many times they can be purchased.

In order to set this up for your Unity app, you need to select the In-App Purchasing option from the Services window within your Unity project. Next, you need to select the appropriate COPPA option, and then save the changes.

You need to have first created your app within the appropriate app store to be able to set your app ID and your in-app purchases. Then once it has been verified, you can set your app ID and set up your in-app purchases within Unity to the same types and costs as what was in the app store.

The amount of money to be made with IAP is always a bonus if you offer these within full price apps. The best way to maximize revenue for IAPs is to carefully watch the IAPs you’re selling and for what amount. If you find you are selling more of the $1.99 items than the $4.99 items, you may want to consider changing the cost of the £4.99 items or increasing the price of the £1.99 items.

The time of year, external factors (e.g., yearly events), and the item itself should all be taken into account when adjusting item prices and choosing to remove some. Make sure you look at all the evidence (hopefully backed up by your app analytics!) before you make changes.

So, the potential revenue can be unpredictable at first, but if you find a pattern, you could make a lot of additional money from a single app.


Freemium means that you offer an app as a free download and provide the user with an IAP option within the app. This business model combines a free app with an IAP option.

Freemium is commonly used now by app developers, as users like to try before they buy. This gives them the free option to test out some of the app features before committing to a bigger purchase.

The amount of development effort here is the same as for an app with IAP.

This business model can be unpredictable. Although you can predict based on previous sales of IAPs, you can’t be certain how many of the free downloads will convert to paid in-app purchase sales. It’s important to maximize your chance of this by designing your free product to show your best features without giving away everything for free right away.

Unity Ads

It’s hard to find out when ads were first introduced into apps, but from what I’ve seen, they’ve been there nearly from the start. However, this monetization method has become diverse in itself, and now there are different types of ads to choose to integrate into your app. With Unity Ads, you are able to select ad categories that are more relevant to your app so that your audience is more likely to engage with them. For more information, please see the Unity Ads Publishers page. The following are different types of Unity Ads.

Interstitial ads are static or dynamic image-based ads. They fill up the entire screen of your device when they are active and are set to trigger at specific times during the flow of the app.

Incentivized ads give the user a reason to interact with the ad. For example, they may be rewarded with in-app currency or items in return for interacting with the ad.

Banner ads are the oldest type of ad. These usually take up the lower sixth of your device screen and are shown at any time, even for the entire duration of your app session. These ads are the least intrusive to the user’s app session and aren’t usually the most interesting to look at. This could be because they’re designed not to draw too much attention away from the app’s main function.

Video ads are usually incentivized. But there are some that simply want the user to watch the ad without offering anything for their attention.

To integrate ads into your Unity app, within the Unity Editor, open the Services Window and select the In-App Purchasing option.

Ads are all about getting clicks and views. The more you have, the more money you can make. But in order to make a lot of money from ads, you need a bigger user base, as payouts are usually from views and clicks in the thousands.

Unity Asset Store

The Asset Store is a unique marketplace for Unity developers. It provides objects to use within your project from individual assets, like a chest to complete projects such as Scrambled Word Game.

Once you have created your project or assets within your project, if you want to try and make more money from your efforts, you can try and sell the project assets and/or the entire project on the Asset Store (providing you own all the rights to your project assets). You earn 70 percent from your sale on the Asset Store (Unity takes a 30 percent cut).

To do this, you need to sign up for an Asset Store publisher account and fill in the relevant information. When you’re uploading your asset, you need to provide screenshots and other metadata to help potential buyers learn more about your asset in order for them to buy it. For more information see the Unity website instructions for how you sell your assets.

What’s Right for Your Project?

The ways that you choose to monetize your app is a decision that must be thought about very carefully. It can affect the type of user your app attracts and the number that convert to buyers.

You need to ensure the type of monetization method you integrate is something that your target user expects, is used to, and wants to use. Therefore, gaining feedback from them about their previous app purchases may give you an insight into the types of monetization methods they prefer using, ads, subscriptions, or maybe IAP.

It may be tempting to offer a range of methods to try and catch the majority of users, but each type you add may cost more to implement. Keep costs low in the beginning, and focus on a maximum of two per project.

If you’re still unsure about which types to use in your app, implement different types across your catalog of apps. If one method isn’t working so well, you’ll know that may not be the best option for your audience. You can then change it to something that may be performing better. It all depends on your feedback.

Continue getting feedback from your users directly and indirectly to assess which monetization method is the best one for you to make money from your project.

The A to Z of App Development 2018

app development 2018

Here’s my next post which appeared first on Simple Programmer.

Apps (short for applications) were introduced to the world via the iPhone in 2007.

In 2008, the Apple App Store was opened, and anyone could create apps. A market had opened that could generate developers enough income to give up their day jobs.

Now, there are two major app stores, Google Play (for Android apps) and the Apple App Store (for iOS apps). Together, they host close to six million apps. This is a massive growth rate in 10 years. And with the next billion users, it’s set to grow even more. Who are the next billion users? They are the next wave of users of the internet. They likely reside in third-world countries that previously didn’t have great infrastructure. However, countries within Africa, where users were previously unconnected, are becoming connected with the construction of 5G networks. This means that these users will need apps that cater to their own needs, wants, and entertainment values just as more developed countries have done over the last 10 years.

Since the creation of apps, development and distribution of these applications has become more complex. Their quality has improved, competition has become fierce, and the ways to develop them has become more diverse.
If you’re new to app development, I hope to give you a brief insight into useful information about apps and smartphones through what I call the A to Z of App Development.

App Store Optimization (ASO)

ASO was introduced to us via the Apple App Store in 2008, but it wasn’t regarded as an important business practice like its older sibling SEO until quite recently.
ASO means you are optimizing your app to be easily searchable in the app stores using specific keywords. Tools like Google Keywords exist to help you find the highest ranking keywords (which are the most searched for) within a certain category. By associating the keywords that are searched for the most with your app, you make it more likely that your app will appear in search results for users.

In order to add keywords to your app, you need to enter them into the appropriate field within the developer console profile of your app in an app store.


Bluetooth is the wireless communication technology that allows a minimum of two devices that have been paired to connect and share data over short distances. This method is the most common way to connect audio devices with portable devices such as laptops, smartphones, and tablets.

It was invented by Dutch electrical engineer Jaap Haartsen in 1994 while he was working for telecom vendor Ericsson. Now, it’s commonly used by all companies and industries to connect their products.


When apps were first introduced, you could only develop an iOS app using Objective-C or develop an Android app using Java. This led to many developers specializing in one platform, and while it was good for developers to know the ins and outs of a single platform, it blocked them from reaching the user base of the opposing operating system. It would also double the cost of an app for those wanting to purchase the development of an app for both stores.

Now, there are a number of solutions that enable developers to code once and release to all stores. We call this capability cross-platform. There are two main ways you can create an app that’s cross platform:

  1. You can create an HTML5 app that allows you to code the app using web technologies like HTML5, CSS, and JavaScript. This is the wrapper that’s compiled into either platform’s codebase in order to make it run on the specific device.
  2. You can use a cross-platform tool like Xamarin or Unity and code the app in C# or JavaScript depending on the tool you use.

Cross-platform enables developers to become specialists (at a high level) in both platforms and reach more users. And, of course, it allows for the potential of more profit.


In app development, there are currently three key devices to develop for:

  • Smartphones
  • Smartwatches
  • Tablets

Smartphones, as I mentioned earlier, were introduced on a large scale to the world when the iPhone was released in 2007. Tablets came next, and again, Apple seemed to succeed in this wave of advances, even though Android tablets were available.

The apps for smartphones and tablets can be shared so the amount of work needed to develop across the devices is minimal. However, if you can, it’s a good idea to develop a difference between your smartphone app and your tablet app. (You may find that tablets should have a different layout to make the most of their screen estate.)

In 2015, Apple released the Apple Watch. It has several iterations, including branded editions like Nike and Hermès. Android watches have been released since the Apple Watch by companies like Samsung. These small devices, unlike tablets, cannot share the same app as smartphones. Because of their very small screens, individual apps (or one complementing your main app) must be created. Different interactions will be executed, and visual designs for smaller screens need to be considered.


Emulators are software that allows app developers to test their app without launching it on a physical device.

Testing on physical devices should always be carried out when developing apps, but because of the fragmentation that exists across mobile devices, having access to all the different devices that your app can work on isn’t financially a good decision.

Emulators allow you to set up different versions of SDKs and device types for operating systems to test your app. In my opinion, you should physically test on a couple of the main devices that carry the latest spec and operating system version, and then use emulators to test the different variations.


Every year sees a new mobile operating system (OS), and because of this, there are a variety of operating systems for apps to run on. This broad range of OSs that are available is usually described as fragmented. Combined with the many devices available across each platform and their varying screen sizes, this means a lot of combinations that your app could possibly be used on.

Apple devices weren’t so bad for this in the beginning, although their variety has expanded since the original size was introduced. Android developers are the ones who need to make sure they perform a wide range of testing and lock down devices and OS versions that they do not want to serve with their apps so as to keep their testing to a manageable amount.


With the introduction of touch-screen devices, gestures (e.g., single tap, double tap, swipe left or right, up or down) are now used just as much as digital keyboard buttons. Gestures help a user to interact more organically with a device than with digital keyboards or precisely selecting digital buttons.

Some apps like Tinder have become famous for their use of gestures within the app. These two gestures of swiping left or swiping right have become so synonymous with the reject or accept feature of Tinder that people only need to reference swipe left or swipe right in conversation for everyone to understand the reference.

Children as young as 1 year old are using tablets and smartphones better than their grandparents because gestures require no knowledge of language and are easy to learn.

As app developers, we need to keep in mind that using gestures instead of buttons to access functionality removes a high barrier to entry for users. And as gestures are easy to describe and learn, the user will be able to use your app faster and more effectively. This provides the user with a good user experience and will hopefully improve the number of users you retain after downloading the app.

Home Button

The home button (this could be physical or digital) is usually the only button on the front of smartphones. This button brings the user back to the first screen on the phone’s display. As an app developer, you need to factor in how your app will function if this button is pressed.


App icons are small unique images that are used to immediately identify your app within app stores and on devices.

They can look any way you want, but it’s usually a good idea to keep this icon within the same brand guidelines used in your app. It’s also good to depict something that represents the main function of your app so that users associate its use with your app icon.

Different stores have different guidelines for app icon graphics. Make sure you follow the correct guidelines for each store you submit to. This will ensure your release process isn’t delayed by having to redesign or recreate your app with different settings at the last moment.


JavaScript is a scripting language mainly used for web development. However, with the introduction of HTML5, JavaScript can be used to create complex apps with a web-based wrapper, so now web developers can create apps for mobile devices using the same skills used to create websites.

When you are thinking of developing your apps, you should consider which technology you want to use and which platforms you want to target. Using HTML5 can give you the benefits of developing using tools like Unity but without the same amount of complexity.


The keyboard is a versatile feature of smartphones. It can be changed to suit the language preferences of the user and even handle multiple languages being input at once (no need to switch between settings options).

The layout can also change to accommodate the user’s international keyboard preference.

Luckily, the user’s keyboard setting is usually something you don’t need to consider as an app developer. The keyboard will be displayed in the default language that you have set for your app.


Apps use the location feature to identify where the user is. Facebook’s popular check-in feature uses the device’s location function to tag user posts with the location. Using location in conjunction with other features can provide more information to other users, and data to the app provider.


Magnetometer allows your device to be aligned in relation to the Earth’s magnetic field. This means your phone will always be aware which way is North so the app can rotate to the correct position and orientation on digital maps.

Allowing your app to use the magnetometer requires a permission that you would need to allow when developing your app.

But, unless you’re making an app that requires this magnetometer functionality, like something that relies on geolocation or a compass app, this probably won’t be a permission that you regularly set up.


There are different types of notifications that devices use: local and push.

Local notifications can be set up during the development phase of your app and are sent to the user depending on the type of notification, i.e., an event notification or a reminder notification. The times that these are sent will relate to the type of notification. Local notifications can usually be managed by users themselves within a settings area of the app.

Push notifications are sent after the app has been developed; they are live notifications to the user from the app provider. These usually give up-to-the-minute short pieces of information to draw the user back into the app. For example, these can be news updates from the company behind the app.


Two main types of orientation exist for devices: portrait and landscape.

Portrait orientation is when the device is aligned vertically, as in a sheet of paper, and a landscape orientation is when the device is aligned horizontally.

As an app developer, you can choose to lock your app to the portrait orientation or the landscape orientation or allow the app components to change position depending on the way the user is holding it.


When creating an app, you can only do so much before the time comes to add a great new feature. In order to do this, you need to enable the relevant permission on that device. This is usually a check box or line you need to add to a config file.

This alerts the user when they download the app that your app will require the use of additional tools like access to your contacts or access to your camera.

As users are becoming more proficient at using apps, they are more aware of access to their privacy and personal data. Some apps may not be accessing personal or private data, but the permissions that your app requires in order to function fully will be listed whenever someone tries to install your app. Showing users this message prior to installing the app gives them a choice and makes them aware of how the app is using their device’s content.

Depending on the permission (and whether it is integral to the main function of the app), you may find that the app cannot be downloaded unless you accept this message or that the app’s features are restricted until you accept these permissions. It’s all up to the user to decide.


QWERTY is the name for the original style of keyboard used in physical and digital devices. The name was formed from the first five letters on the left side of the keyboard.

Depending on the input fields within your app, you may want to restrict what type of keyboard is shown to the user at certain times. For instance, restricting users to the numerical keypad in a telephone number field may help you reduce user errors.

The decision to switch out this keyboard or lock a field to a particular one is a design decision that you should make when designing forms.


As smartphones and tablets can be used in both portrait and landscape mode, the ability to rotate your app is also something you should consider when designing and developing your projects.

Yes, giving the user the option to interact with your app on different orientations makes it more accessible, but this will add to the design and testing time. You will need to ensure that your app functions and looks correct in both views and that it can move between both seamlessly at different points through the user journey.

To make this easier, you may decide to lock the rotation on certain screens, but this restriction may seem inconsistent to users if they can rotate it on some screens, and it’s not totally obvious why they can’t rotate it on others.

Always keep the user, your project time, and testing in mind when considering rotation.


Resolution is the number of pixels that are able to fit on a device’s screen. As the years go on, we are introduced to mobile devices with even better screen resolutions, meaning that they can fit even more pixels in to give us a sharper, clearer and overall better picture from our screens.

Because of the fragmented landscape of mobile devices, when designing your app, it’s important to know the devices you target and the screen resolutions you will support. You will also need to make sure you test upon those. Differences in resolution can mean that objects positioned perfectly on the right hand side of your screen on one device may appear in the middle on others. Test for these differences, and develop solutions.

Status Bar

The status bar provides information to the user with icons. It can sit on or be hidden at the top of a device’s screen.

This bar shows users that there is something that an app wants you to be aware of and, obviously, the status of your device, e.g., whether the Wi-Fi is connected, whether you’re connected to a Bluetooth device, or whether you’re in airplane mode, all via icons.

If you use notifications within your app, think about an appropriate notification icon that fits with your app style so your user can identify it easily.


Smartphones have been around since before the iPhone was launched. BlackBerry dominated this sector prior to 2007. These devices usually had a full-but-mini QWERTY keyboard, and the screen would take up the rest of the front. But the iPhone changed this. They showed that a full touchscreen was not only useful to users but also easier to engage with than tiny keys.

BlackBerry tried to launch their own range of phones with full-length touchscreens, but unfortunately for them, Apple already had their audience.

Touchscreen succeeded and was embraced quickly because of the low barrier to entry with gestures, great design, and onboarding process by Apple.

Because of this massive success in the change with how we interact with devices, more and more products like bank ATMs, POS systems in shops, etc., are utilizing touchscreen instead of physical buttons.

Although voice is now more widely used to communicate within apps on devices, using the touchscreen is still the primary source of input. This is because it’s easy for users of all ages to interact with. But it does depend of your audience’s level of experience with apps. So, as an app developer, you need to keep in mind that utilizing the touchscreen is great, but it needs to ensure that how you use it cannot be misinterpreted. For example, pressing and holding an object to interact with it isn’t something that you would naturally think of doing, while tapping is more intuitive.

USB Port

The USB port is always present on devices. It’s the primary way to charge phones, so it’ll always be a necessary feature until wireless charging takes off everywhere.

Micro USB was the dominant choice for Android devices (Apple always did their own thing), but now with the introduction of USB C, it seems that the world is waking up to the fact that we don’t want to have five different cables to charge five different devices.

USB C has been added to MacBooks and phones from both Apple and some Android phone manufacturers. So hopefully recharging will be a lot easier in the future.

So why’s this related to apps? Some apps can run directly on a USB device without the need to run on a device. And because of the portability of USB devices, apps can be device-agnostic and can run on pretty much most devices. A good example of when a USB app would be needed could be a support app for a company’s system administrator who’s upgrading all the computers and can’t do it remotely for whatever reason.

Some Android apps can be run from USB, but I highly doubt you’d have this flexibility with iOS apps.


Vibration (also known as haptic feedback) was introduced to mobile phones very early. In phones as old as the Nokia 3210 and in games like Snake, vibration occurred when the phone rang, or you’d get haptic feedback when you caught your object in a game.

Haptic feedback is a good way to provide non-textual or visual feedback to a user to alert them to something or a change in state. It shouldn’t be used everywhere or excessively. Ensuring that haptic feedback isn’t being overused within your app should also be considered when testing your app.


Wi-Fi is a technology that many devices like laptops, computers, smartphones, tablets, etc. use to connect to the internet.

As an app developer, you need to make a decision whether your app will need the internet to function or not. You may want to serve your app content from a content delivery network via cloud computing solutions, so your app may always need to be connected. Or, you may want to use a cloud database to store the scores for your app.

These are acceptable reasons, but it’s always a good idea to build in functionality that allows your users to continue using your app when the internet is not available. So, when it comes back, you can send up or retrieve data again seamlessly without the user’s session being disrupted.


Xamarin is a cross-platform tool that allows developers to produce apps written in C# with a predominantly shared codebase across multiple platforms.

Using Xamarin tools allows you to create native Android, iOS, and Windows apps with native user interfaces. This gives developers the ability to create apps that the users will pick up quickly due to being presented with a UI that they are used to.

However, if you want your app to look consistent across the platforms, you can override the native rendering and implement custom renderer for individual components.

Yearly Releases

Every year, Apple and Google update their iOS and Android operating systems, so it’s important to be aware of the changes that these updates will bring and how they will affect your current apps in the stores and future apps.

For example, with the release of iOS 12, starting in March 2019, Apple is making it mandatory that all new apps and app updates for iPhone, including universal apps, will need to be built with the iOS 12 SDK to be able to support their new iPhone XS and iPhone XR, but especially their iPhone XS Max.

Make sure you get notified or keep up to date with these changes so your app project timescales won’t be negatively affected.

Zones (Time Zones)

(OK, I cheated on this one, but it was really hard to find something related to “Z”).

Time zones can be important if you have specific timed events that trigger notifications within your app.

Depending on where the user is, you may want this to trigger locally to them. Or, you may want this to trigger at the same time everywhere. You may want to consider where the majority of your audience resides so if you do choose the latter option, the majority of your users can enter your event at the same time.

This will need to be considered during design and development. Make sure you also think about a good way to test that this works!

Now You Know Your ABCs…

Apps have been around for 10 years now, but they are going to be around for a lot longer. It’s important to know the basics and background of what you’re working with so you know where you’re going.

If you’re new to app development or if you’re continuing to add to your app portfolio, I hope this has provided you some useful information so that you can build great app experiences.

Quiz Scramble Template on Sale!

Earlier this year, I redeveloped my app Werdz Movies from UnityScript into C#.

This was just a first iteration. I redesigned the interface so that the hint is always on screen and I still need to add in the power-ups somewhere. These will eventually become in app purchases, something I never got around to doing in the released versions on the App Store and Google Play.

I designed this new version as a template with basic graphics so that anyone can use it and make it their own. After doing this, I packaged it all up and uploaded it to the Unity Asset Store.

This has been available since the 23rd October but from November 27th to December 8th PST it’ll be ON SALE!

You’ll be able to buy this with a massive discount of 30% off.

So if you’re interested in creating your own version of Werdz Movies maybe with games, historical figures or TV shows trivia, grab this now from the Asset Store. It’s only on sale for a short time so make the most of it.


Testing Your App Using TestFlight

Here’s my next post which appeared first on Simple Programmer..

There are many types of testing that you can add at different phases of your project. Your last line of defense is testing within the final stages of the project—where you can catch those last-minute defects that can potentially harm your product’s use, damage its value to the user, and tarnish your company’s reputation as a manufacturer of high-quality items.

Various tools exist to assist you during these final stages. One of the most well-known tools for testing iOS apps is TestFlight.

If you’ve never used TestFlight, this post will be an introduction to the tool and will describe how you can best use it during your project to ensure few to no defects affect your final product.

What is TestFlight?

TestFlight is an online tool that allows you to install and test mobile apps “over-the-air.” Historically, app developers tested their projects on actual devices that had to be connected to the development machine using a wire to get a new build. Over-the-air allows developers to distribute their latest builds to testers without the need to connect to the phones physically. Because of this, new builds can effectively be sent to testers in any part of the world.

Who should use it?

TestFlight is perfect for small businesses that don’t have access to a large in-house testing team. And since it’s free, it allows for more businesses other than just revenue-generating companies to use it.

But it can also be good for enterprise companies with remote testers. The access and ease of distribution to up to 10,000 external users and the ability to gain their feedback is extremely useful to companies of all sizes.

When was TestFlight released?

On December 23, 2010, TestFlight was founded by Benjamin Satterfield and Trystan Kosmynka. At the time of its initial release, TestFlight was a single platform designed with the intention of testing mobile apps for both Android and iOS devices.

In 2012, TestFlight was acquired by Burstly, which raised a considerable amount of capital from venture capital firms in order to develop further features and launch TestFlight Live (a now discontinued service providing the user with real-time analytics and engagement metrics).

In February 2014, Apple acquired Burstly. By March of that year, they terminated support for Android devices.

How has TestFlight changed since being acquired?

Today, TestFlight is one of the many options for you to use to test your iOS app. Although there are alternative systems, a few of these still utilize TestFlight to do their app build distribution, especially since the limit for external testers was increased to 10,000 users. With that number of users, you’ll be sure to receive adequate feedback and get enough testing done to ensure a high-quality level of your app.

Currently, you can use TestFlight only for apps developed for Apple devices, as it’s available only to developers within the iOS Developer Program.

Once signed up for this service, you can distribute your app builds to internal or external beta testers who can provide you with feedback about the app. Along with this service, the TestFlight software development kit also allows developers to receive remote logs and crash reports from testers. Being able to gather data from users when they have experienced an issue can be invaluable, as some defects can be difficult to reproduce. The data from these crash reports could provide you with information to help you track down the issue and fix it before it affects anyone else.

At what stage should you use TestFlight?

Although TestFlight would be great during the earlier phases of development to test your initial builds, you need to upload a release build in order to use TestFlight. Using release builds to perform initial testing on isn’t typical, because they contain less debug information. In the event of a crash, you won’t have sufficient details in order to step through the code, find out what happened, and try to fix it.

Release builds are created when the developer is satisfied that the major bugs have been caught and it’s ready to be a beta candidate build. This is a close representation of the final version that will go to customers. Generally, the build is stable with few to no crashes. Any issues encountered at this phase usually require only minor tweaks, so release builds are better for beta candidate builds.

You can also use TestFlight after release to get live information about your app’s performance and feedback from users. Gaining ratings and reviews once an app is live is challenging, so giving users a way to easily submit feedback may help combat this issue.

What are the benefits and drawbacks of TestFlight?

While the history behind the product’s evolution gives you an idea of its features, there are many reasons why you may, or may not, want to choose TestFlight for your testing phase.


Wide range of users
Being able to distribute your app to up to 10,000 external users over-the-air gives you the opportunity to get feedback for your app from a large number of users that you wouldn’t have previously been able to reach.

Having a beta testing group at this maximum amount is most common with game companies, as they have prospective users registering ahead of time to test the latest versions of a game iteration.

For normal apps, this number of testers is very large. I would typically expect a maximum of a couple hundred beta testers. Because remember, the more testers you have, the more test results you have to analyze and feedback you’ll need to review.

Keeping the number of beta testers to something sensible is recommended, no matter what maximum limit TestFlight provides.

Testing on multiple apps at once
You can test up to 100 apps at once with either internal or external users. You can also upload different iOS app builds—watchOS apps, tvOS apps, and iMessage apps—at the same time.

Internal users
Up to 25 members assigned to your team in iTunes Connect can also test your app on up to 30 devices.

Unlike external testers who will have access only to the build that their assigned link points to, internal testers will have access to all builds of your app. If you have multiple versions of your app—for example, a free and paid-for version—the testers could have access to each build of these different versions so you can get one person to test multiple apps.

Quick distribution
The tool allows you to quickly distribute your app to a specific set of beta testers over-the-air immediately. You may choose to build different versions to perform A/B testing of your app with your testers. Being able to send a specific build to a number of users at once will help you gain more results faster.

Easily accessible
TestFlight is integrated within the Apple Developer Dashboard that you need to use in order to distribute your app within the App Store. You only need to switch tabs to gain access; no separate login is required.


iOS only
If you’re developing a cross-platform tool, this will allow you to test and receive feedback easily only on your iOS build. You’ll have to do additional work if you want to test the Android build.

Extra review needed to distribute via TestFlight
Apps that use TestFlight will require a Beta App Review and must comply with the full App Store Review Guidelines before testing can begin.

This is because your app is effectively going out to a select group of the public, so the Apple team wants to ensure that the build that is distributed is of the same quality as the current releases in the App Store.

Just like with the normal app submission process, if your app has significant changes between versions, you’re required to resubmit it for review. This will add extra time to the last phases of your app’s development before it reaches the public.

After you have completed beta testing, you will need to submit your app for review through the usual iTunes Connect screens.

Limited time for beta testing
Submitted builds are accessible from TestFlight for only 90 days after invitations to the testers have been sent. The app will stop writing after these 90 days, so you’ll have to either update your beta submission or get all of your testing completed within those 90 days. This restriction doesn’t affect your internal testers, only those external to the project.

Restricted to specific builds
Only release builds that are signed with the correct provisioning profile and distribution certificate are allowed to be uploaded for beta review. So the build needs to be signed appropriately in order for it to be built and accepted.

Only for devices running iOS 8 and above
A new iOS version is released every year, but not everyone upgrades and not everyone can upgrade, because Apple chooses to drop support for “old” versions of iOS hardware within about three years. This does slightly limit the reach to your audience, as you have no idea what devices they are using and whether their devices support iOS 8.

No application programming interface for continuous integration/continuous deployment
The upload process has to be carried out manually, as there is no way to integrate continuous integration, delivery, or deployment tools into iTunes Connect. So this will slightly slow your progress during testing.

Is TestFlight for you?

Testing your app is a fundamental step in the process of developing one. Without testing, you’re blindly throwing your creation into the wild with no assurance that it will even work for your potential customers. TestFlight is a robust tool for iOS testing that’ll help you manage your beta testing stage effectively and get it out to potentially thousands of users.

I can completely understand the excitement to develop your idea into something tangible, but you must keep in mind that the goal is to create a great app, not simply to distribute anything that resembles your idea into the app stores.

To do this well, you need to remember that integrating thorough testing (even if you’re a team of one) into your development is essential for building a robust product and successful project. And gaining feedback from beta testers via TestFlight before your product is opened up to everyone could reveal some key insights.

This testing could change some big features and could possibly put your app on the course to becoming extraordinary. So while there are several drawbacks to using TestFlight, I think the positives ultimately outweigh the negatives and make it worth considering TestFlight as a resource for beta testing your next app.

Releasing Your App to the Store in Style Part 3

Here’s my next post which appeared first on Simple Programmer..

During the first two posts in this series on how to release your app to the App Store, I discussed the importance of configuring the first two screens of your App Store page.

In Releasing Your App to the Store in Style Part 1, I stepped through the App Information screen and why each setting (for example, the title and category) is important to help drive more users to your page.

In Releasing Your App to the Store in Style Part 2, I discussed how the price and where you make your app available could affect your sales, and also how you could use this to help with trialing your app on a smaller audience.

In this post, we’ll discuss what you need to configure before you can finally submit your app for review to Apple, before you plan for that all-important release date.

We’ll discuss each section of this screen in the order that they currently appear so you can read through this post and the screen at the same time from top to bottom without having to jump back and forth.

Let’s go!

Version Information

This section gives prospective users a first glimpse at your app. Sure, the icon may have drawn them in, but you need to have your best images here. If your images aren’t high quality, they will not convince viewers to download your app.

App Screenshots

For the current generation of Apple products, if your app runs on an iPhone, you must provide screenshots appropriate for a 5.5-inch display. The Apple guidelines state that “screenshots must be in the JPG or PNG format, and in the RGB color space. App previews must be in the M4V, MP4, or MOV format and can’t exceed 500 MB.”

You will upload screenshots for both iPhone and iPad in this section. If your app supports both iPhone and iPad, you need to add at least one screenshot for iPad. You are allowed up to five screenshots for iPhone and five more for iPad.

Read iOS Screenshot Specifications for more information on the guidelines you need to follow when creating your iOS screenshots.

Screenshot Options

You have a few options available when managing your screenshots in this section.

Media Manager

This option allows you to upload individual sets of screenshots for each iPhone or iPad size. You can also make any one device use the default 5.5-inch display screenshots by checking a checkbox next to each device section.

The benefit here is that if you have different designs for different devices, you can showcase both on the store to your users. A small downside is that it may take a little while longer to gather and format the screenshots to the correct sizes. But if you went to the trouble of creating new designs, why not put in the extra effort to make sure they’re seen by as many people as possible?

For more information about the Media Manager, read this Get Localization post.

Choose File

This option allows you to select the images you want to use for screenshots from your file system.

Delete All

This option will remove all screenshots and any App Preview files you have added to the 5.5-inch display section. It’ll save you from having to remove them individually. Being able to remove everything at once will be useful if you have updated the graphics of your app and want to change them all.

App Preview

An App Preview is a short video users watch right on the App Store that lets you demonstrate the features and functionality of your app. You are allowed only one app preview.

This preview video is a great marketing tool, but don’t do it if you can’t create a high-quality, effective video that equals the brilliance of your app itself. Users may overlook your app if they’re turned off by the video.

If you really want to make a video, but don’t have a large budget to hire someone, please, do it yourself only if you know you can produce something spectacular. If the video is low quality, that indicates that your app could also be of low quality. And that’s the last thing you want.

One idea for those with small budgets is to look for contractors on Fiverr. Most jobs start from £5 (extra services may increase the price, though) and you can get a few free revisions included in that cost to tweak your project if you’re not happy straight away. Just remember that the devil is in the details. The more details you provide, the better your chances will be that your first version comes back close to what you are happy to use.

In addition to being high quality and well-made, it needs, above all, to be short. Time is money, so make sure your star features are showcased quickly in your video. Between 15 and 30 seconds should be your target range. If you think your video may be too long, try it out on a few people and get their opinions before you spend time reducing the length.

Read App Preview Specifications for more information on the guidelines you need to follow when creating your App Preview.

Other Sizes

When you add in your iOS screenshots for the 5.5-inch display, these will be resized and used for the other sizes: 4.7-inch display, 4-inch display, and 3.5-inch display. Again, the benefit here is that if you have different designs for different devices, you can showcase both to your users on the store.

To add custom screenshots to the Other Sizes section, go to the Media Manager.

Promotional Text

Waiting for your app to be reviewed can take up to a week if you’re a new publisher to the Store.

However, promotional text gets updated to your App Store page straight away, bypassing the submission process. It lets you inform visitors to your page of any current app features quickly.

This text appears above your description on the App Store for those with devices running iOS 11 or later.


After the images, the description provides the user with the greatest insight into your app and its features.

Overloading the reader with every little amazing feature your app has is not the best strategy. Giving someone too much information may leave them bored by the time they get to the end (if they don’t lose interest and switch to something else halfway through).

And giving them something too short may not intrigue them enough to download your app and see for themselves.

You need to find a balance where you deliver the best information in a short, snappy pitch. List your best features to catch the attention of those that skim-read.

This description will also be used for your Apple Watch app, so you may want to keep it as short as possible. It really depends on whether you mind having users scroll to read the full description in their Apple Watch.

You also need to be thoughtful in the words you use to describe your app. Use keywords in your description you think a potential user will search with to make it more likely that your app will show up in their search results.


This field is like the description in that you fill it with keywords. However, unlike the description, you can put in words that you wouldn’t use to describe your app, but users may search with. For example, the Google Sheets app doesn’t contain the word “number” or “calculation” in its description, but as users are familiar with associating these words with this tool, they may use them when they search for that app.

Make sure you add at least one keyword into this field to improve the chances of your app being listed in search results. Separate your keywords with a comma. (No need to add a space! You’ll just be wasting precious characters.)

Picking relevant keywords for your app has become as important and as much of an art as picking the keywords for your website. For this reason, choosing your keywords now has its own name: App store optimization or ASO. Tools like Google Trends and Google Keyword Planner will help you figure out what terms users are searching with the most so that you can find the relevant keywords to add into your app to ensure it appropriately turns up in the most search results.

ASO can be incredibly complex; the best keywords to use will depend on your app. I suggest that you spend a bit of time on trying to select the best keywords using the tools I described above to get you started.

Support URL

Visible on the App Store beneath your description, the URL tells users where to go if they need support information for your app.

Marketing URL

Also visible beneath the description, this URL tells users where to visit in order to gain marketing information about your app. For example, you may want to provide more in-depth information about the features of the app, the background of why and how it was made, any information about you in relation to the app, etc.

iMessage App

The iMessage App allows you to create an app extension that lets your users interact with your app within Messages, extending the functionality of your app. Users can interact by creating and sharing content, adding stickers, making payments, and more, without ever leaving their conversations.

The iMessage framework is available in iOS 10 or later.

You can add screenshots to your iMessage App extension here in the same way as the iPhone and iPad version detailed above.

Read the iMessage page for more information about iMessage.

Apple Watch

Apple’s wearable device Apple Watch has grown in popularity since its release in April 2015. By developing an app that is compatible with Apple Watch, you open yourself up to a wider range of people.

As the display for Apple Watch is smaller than a normal phone display, you’ll need to design an icon that’s a suitable size but also ties into your app across other devices. Upload your icon in this section.

In this section, you also add in your screenshots for the Apple Watch app. You can have up to five screenshots for the Apple Watch (just like the iPhone/iPad sections). Similarly, the options for the Media Manager, Choose File, and Delete All are also the same. As mentioned earlier, there’s no separate section for the Apple Watch description, as it shares the description defined for the iPhone and iPad.

Read the Apple Watch Screenshot Specifications page for more information.


The “build” is the application file that you have produced using your development tool. This is the section where you actually upload the build that will become the public version of your app. You can create the build using Xcode 6 (this is the current version stated) or later. If you are unfamiliar with Xcode, it’s a piece of software known as an integrated development environment (IDE) that can be used to develop apps for Mac, iPhone, iPad, Apple Watch, and Apple TV.

Now, you can use a number of different development tools, or IDEs, to create your iOS build. Once you have created your build, you will need to upload it to iTunes Connect. iTunes Connect is Apple’s portal for developers to manage their apps.

The easiest and latest way of uploading your build is via the Application Loader 3.0 (this is the current version stated) or later. The Application Loader is a hassle-free graphical user interface, which connects to your iTunes Developer account and allows you to upload a new build or add new in-app purchases to a project.

Once you have created your release build, you select this IPA file from the Application Loader, and it will verify that your app is correctly configured to upload. If there are any issues with the information that you have provided, you will be shown these details so that you can fix it. Once uploaded, you will see it in iTunes Connect under the Build section.

This section also shows the build version extracted from the build file you uploaded and the date you uploaded the file.

If you included any assets within your build, these are also extracted and shown here. For example, if you included your app icon, you will see it shown above the version number on the left.

General App Information

App Store Icon

This icon is the first piece of content from your app that users will come into contact with, so you need to make sure it’s high quality. You also may want to ensure that the image is representative of your app’s core functionality so the audience will know intuitively what the app is about.

For example, the App icon for Google Docs is a document with lines on it. Most software users associate this image with a file, piece of paper with text, or document, which automatically suggests the functionality of the app. Linking your app icon and app functionality will lower the barrier to entry and help you retain users.

The icon uploaded here will be used on the App Store. It must be in the JPG or PNG format, with a minimum resolution of at least 72 DPI, and in the RGB color space. It must not contain layers or rounded corners. Your app icon must also be 1024 x 1024.

For more information, please see App Icon Specifications.


This is the current build version number of the app that you are adding. It is advised that the numbering format follow standard software conventions (usually “major.minor”).


This section is related to the age rating for your app, not the entertainment tagging that users provide. The rating is automatically calculated for you to make sure that all apps are rated objectively.

To get your app automatically rated, you read through a list of categories and check either none (no examples of this occur within your app), infrequent/mild (only some examples occur within your app), or frequent/intense (many examples of this occur within your app) to each option.

Once you have entered an option for all categories, the system will calculate an appropriate age rating based on your answers.


This is the name of the person (or entity) that owns exclusive rights to your app. The year the rights were obtained are placed before this name.

Trade Representative Contact Information

This section outlines the contact details of the trade representative contact for your app. It is to provide additional information for the Korean App Store. If you’re a hobbyist or a solopreneur, your contact information will be provided here. If not, you should list whoever handles your business’s external communications.

If you wish for this information to appear on the Korean App Store, then check the box next to the text “Display Trade Representative Contact Information on the Korean App Store.”

If you provide your details in this field, your information will be displayed in the Korean App Store. If you don’t wish to show your contact details in the Store (which is perfectly understandable), you can choose to omit your details. This shouldn’t prevent you from having your app in the Korean App Store, but you should double-check with an Apple representative to confirm.

By default, your contact information is placed within these fields. If you remove your details, you may find that they default back to using your real contact details. The only way to remove your details is to add something like “no address” into these fields. Again, I’m not sure how this will affect your submission and being displayed in the Korean App Store, so you should seek advice from an Apple representative.

If you don’t want your app to be available in the Korean App Store, you need to disable the app within the territories section in the previous screen, “Pricing and Availability.”

Routing App Coverage File

If you would like to specify the geographic regions supported by your app, you can do so by providing a file in the format GeoJSON and uploading the separate GeoJSON file in this section.

Game Center

This option includes your app within Game Center. If you have added in functionality to your app that makes use of the Game Center features, once you enable this option, your build properties that relate to Game Center will be extracted and displayed here.

App Review Information

Information

If you give users the option to sign into your app using a particular social media channel, Apple will need a social media account to test this, enter your app, and test its functionality.

In order to proceed through the review process, your username and password credentials for any social media accounts you want to be tied to your app must be valid and active for the entire review process. If they aren’t, your app will be denied and you’ll have to start again.

If you want users to sign into your app, check the “Sign-in required” checkbox and provide a username and password in the hidden fields.

Contact Information

You need to include the contact information of the person the App Review team should contact if they have any questions or need additional information during this process.


This section can be used to provide any additional information about your app that can help during the review process. Include any information that may be needed to test your app, such as app-specific settings. Providing these here may speed up your review.

Version Release

After the app has been approved, Apple can release the app straight away if you check the option “Automatically release this version.” However, most publishers that aren’t hobbyists usually have a marketing strategy with a whole release timeline etched in stone so that they can build anticipation for their product.

If this kind of plan is what you have in mind (albeit maybe on a smaller scale), you may want to choose the option “Manually release this version.” To delay the release of the app until a certain date after it has been approved, you can choose the option “Automatically release this version after App Review, no earlier than [provide your chosen date].”

The earliest date your app will be made available on the App Store is based on your current time zone. If the App Review process isn’t complete by this date, the version will be made available directly after it has been approved. So if you want to maintain control over the release of your app, make sure you allow for ample time between submitting for review and getting your app approved.

Once you have submitted your app, it will be set to the “Processing for App Store” state. While your app is in that state, you can’t get new promotional codes, invite new testers, or reject your app. You can upload a new build, though, in case you missed something small but significant.

After it has been approved, the app will move to the “Pending Developer Release” state. Once it is in this state, you’re able to generate and give out promotional codes, continue beta testing, or reject the release and submit a new build (because, you know, accidents can happen).

So that’s it!

I’ve shared with you everything that I’ve learned so far about how to create a great App Store page.

Having this page configured to a high quality will put you ahead of the competition. You’ll drive more traffic to your page and downloads of your app will increase. But actions make all the difference. Make sure that you put what you’ve learned into practice as soon as possible.

Once your page is live, it’s important to check how your page is doing by looking at the analytics surrounding your page.

The algorithms that Apple and Google use when listing your app within search results change all the time to make sure that no one publisher remains on top.

Because of this fact, you will need to adjust the content of your page accordingly to try and make sure you keep getting a high amount of pageviews and hopefully downloads.

It’s not easy sailing from here, but you’ve done a great job in getting this far.

Good luck with your release!

Releasing Your App to the Store in Style Part 2

Here’s my next post which appeared first on Simple Programmer..

Configuring a great App Store page is usually one of the last stages in the app development life cycle. Because it comes at the end, it is sometimes overlooked, or the information is added in a slapdash sort of way, without much time or attention dedicated to the content.

However, even if you have created a great app, no one will find it if you don’t put some thought and attention into the screens on the Developer Dashboard that make up your App Store page. And even if by some sheer stroke of luck, a few people manage to find your store page, if what they see and read doesn’t convince them to download your app, all your efforts will have been for nothing.

Two key aspects of configuring a winning App Store page are getting the pricing and the availability right.

The price of your app can make it more or less appealing to users, depending on who your audience is and what platforms (iOS or Android) you release to.

And availability of your app can also affect your sales and analytics results. If you release to too wide an audience when your app hasn’t been tailored for all locations, you may hinder your app’s progress.

You must find that balance and use your findings to guide how you configure your App Store page.

In this post, we’ll delve into how to set Pricing and Availability—as shown below—in a way that gives your app the best possible start in life.

You’ll learn to set up the price, set up a price change schedule (if necessary), and set the availability of your app.

Setting Your Price

You should already know from your chosen business model whether you want to sell your app for a fixed cost or price it as free. You would have gained all of this information from the idea validation and research stages of development, and from audience feedback and competitive analysis.

We tend to equate price with quality, so your initial instinct may be to price high and at a fixed cost. This strategy has been known to work on the Apple App Store, as the typical user of iOS devices prefers high quality. But if you try to use the same technique on Google Play, you may find that users are less likely to buy your app. This is because apps in the Play Store usually sell for lower prices or are free, without this being indicative of their quality.

Please be aware that if you decide to sell your app, you must have a Paid Application agreement.

What is a Paid Application agreement?

The Paid Application agreement is a contract you have to review in order to sell apps. You don’t need to submit anything to Apple in order to be compliant with this agreement. It’s simply an online form that you complete with the necessary bank and tax details.

In order to review the agreement, sign into the Apple Developer Account page and select Agreements, Tax, and Banking.

Under Request Contracts, click Request for the iOS Paid Applications contract type. An agreement will appear.

After you review the agreement, check that you have read and agreed to the contract, then click Submit.

The iOS Paid Applications contract will now be displayed under Contracts In Process. You then need to set up your Contact Info, Bank Info, and Tax Info in order to get your sales paid into your account.

For further steps on the Paid Application agreement, please read this step-by-step guide.

What’s the best price for my app?

Only you can decide that, but there are things you can research to guide your decision. Look at similar apps currently on the App Store to help you figure out an appropriate cost for your app. If you can, try to find out how many downloads these competitive apps have had. When pricing your app, take into consideration how long it took you to create your app and how much effort you have put into creating it.

Get feedback from your target audience to gather their opinions about what they would pay for your app. Ask strangers for their opinions over direct friends or family. Strangers won’t care so much about your feelings and are more likely to give you their honest opinion and thoughts. If you’re not a social butterfly, talk to friends of friends, colleagues at work, or online users via groups such as Facebook groups or forums. Ask these people a specific set of questions that will help you justify your price model.

Use the feedback you gain from your target audience and competitive analysis to come up with a price that’s suitable for your users.

Before you set your price …

You should take a look at the All Prices and Currencies link, which takes you to the pricing matrix that details the pricing tiers for each territory. A territory is a country where the Apple App Store can distribute apps.

Pricing tiers are what you use to set your app price. Each tier is of a different value. The lowest tier is Tier 0. This is the tier you select if your app is going to be priced as free.

There are 87 pricing tiers and seven alternate tiers available for you to pick from. The pricing tiers are set by Apple, and they vary across territories.

How do you set a price?

In the Price Schedule section, you will see that you already have a default value set to Tier 0. The Start Date will be today’s date, and the End Date will be “No End Date.”

Select Plan a Price Change to change these defaults.

You will then be presented with a table where you can set the Pricing Tier, Start Date, and End Date for your pricing change.

The Start Date is the date that this new price will come into effect on the App Store. The price changes at the beginning of the day. To make the price change immediately, select “Today.”
The End Date is the date that this price reverts back to the prior value (if you’re setting it for the first time, this will be the default of Tier 0). Selecting “No End Date” will set this price permanently. Prices change at the start of the day. One-day sales have to end at the start of the next day.

Promotional Pricing

You also have the option to configure any promotional pricing periods. For example, if you have a launch price of 99p (or USD $0.99), then you can schedule this so that after a month it increases to £1.99.

Price changes and promotional offers are something that are good to have planned prior to configuring your App Store page.

It’s important to understand how to use price changes to build up scarcity by lowering the price for short periods. But you must be careful, as many users equate price with your level of quality. Ensure your full price reflects what you think is the accurate value of your product.

A good example would be to run a Summer Sale promotion and cut the price of your app by 25 percent for one week. By advertising that the sale is only on for a short length of time but not stating when it will end, your app may get more downloads, as buyers will be uncertain when the original price will be reinstated. However, if you do feel compelled to advertise a certain time period, don’t state anything longer than three days. If you do, buyers will think they have time to come back to it later. The next thing you know, more than three days have gone by, the sale is over, and those who were keen on downloading your app are no longer interested, because they didn’t get a reminder that the sale was ending. Again, make sure you plan this carefully.

Keep in mind also that too many price changes may lead users to believe that you don’t know what you’re doing or that your product just isn’t worth the higher price. Also, if your users know your app frequently lowers in price, they may decide to strategically wait until it drops, in order to get a bargain.

Lay out a plan for when and why you will schedule a price change. Use your marketing channels—Facebook page, website, et cetera—in order to properly communicate these changes. If a special occasion like Christmas is coming up, consider lowering the price for a set period and posting when you’re having the sale.


Availability is where your app will be available. Setting this means you determine which territories your app will be available in. You can select individual options from the 155 territories currently supporting the App Store or by choosing Select All, which will highlight all territories.

Yes, you may think that in order to get the most amount of traffic, you should make your app available to the maximum amount of users. But if you plan to serve only a specific market, or are releasing your early versions to gain feedback, you may want to limit your audience to certain territories.

Companies like Supercell are known to carry out this type of strategy. They frequently do soft launches in Canada to test their ideas and see if what they have just created is a hit, is a miss, or needs a bit more work. If they have a hit, they then open the app up to all of the other territories. If not, they move on to the next idea. Their soft launches differ in length of time, and in whether they release to iOS and Android simultaneously, or one following the other if the initial release receives good enough results.

Volume Purchase Program

This program gives certain groups, like academic institutions, the option to gain a discount when purchasing large volumes and multiple copies of your app.

If your app targets clients that have multiple devices, you may want to have this option. Places like schools and businesses have multiple smartphones and portable devices; therefore, every device would have an individual app. Giving a discount could encourage your clients to buy your product.

These are the options you can choose from in this section:

  • Available with a volume discount for educational institutions
  • Available with no discount
  • Available privately as a custom B2B app

Bitcode Auto-Recompilation

Bitcode refers to the type of code that is sent to iTunes Connect. This is known by its full name of “LLVM Bitcode.” Sometimes Apple automatically rebuilds apps that include bitcode to improve hardware support or optimize Apple’s software—for example, to downsize executable sizes. If Apple needs to alter your executable, then they can do this without a new build being uploaded.
If you want to retain full control of your app, you can opt out of using bitcode. To do this, select the option: “Don’t use bitcode auto-recompilation.” Checking the box means that you have opted out of having your app auto-recompiled.

However, you may want to consider granting permission of this feature. If you disable bitcode auto-recompilation, a few things may happen:

  • Your app may be unavailable for some devices.
  • Your app (including when it’s within an app bundle) may become unavailable whenever apps must be recompiled.
  • If your app is unavailable on the App Store, then Universal Purchase, re-downloading, and Family Sharing won’t work unless all platform versions have been approved.

To make sure your app remains available on the App Store, you need to upload a new build of your app that contains bitcode, test it, and submit that build with a new app version to App Review.

To read more about bitcode, see Apple’s support page.

Where to next?

You now have a thorough understanding of how to set up pricing and determine where your app will be available.

In this post, I’ve taken you through:

  • Pricing tiers and how to set a price for your app
  • The reasons you might choose to make your app free or sell it at a fixed price
  • Paid Application agreements
  • Promotional pricing
  • Apple territories and availability
  • The volume purchase program
  • Bitcode auto-recompilation

Your App Store page is beginning to take shape.

Releasing Your App to the Store in Style Part 1

Here’s my next post which appeared first on Simple Programmer..

It seems like everyone’s making apps these days, and maybe you want to be part of it, too.

Maybe it’s to help you build that passive income you’ve always wanted, maybe it’s a hobby, or maybe you just want to cross it off your bucket list.

It’s hard to believe App Stores have only been around since 2008, a year after the release of the first iPhone in 2007. At that point there were only over 800 apps in the App Store. Now, there are over 2.2 million iOS apps in the App Store alone (as of May 2017).

Knowing there’s massive competition, you still want to go ahead and release an app yourself. That’s great. A little competition never hurt anyone.

You’ve done the hard work of designing, developing, and testing your app, and you’re ready to upload your build.

So how do you get your new, well-built, and well-designed app noticed in an ecosystem where everything is fighting for attention already?

First off, put together a really great store page to make sure when it’s seen, it gets downloaded. A catchy title and making sure it’s placed in the right category can get you far, but there are a few more things you can do to improve your app’s chances of getting discovered.

A quick note before we begin…

Developing an app requires an overall knowledge of the different areas within the Developer Console, so before releasing it to the App Store, you’ll need to have already done the following things:

  • Used XCode to create your build
  • Created debug, development, test, and release builds
  • Signed builds
  • Created provisioning profiles
  • Fully tested your app
  • Created an Apple Developer account for iOS (be aware this requires a yearly purchase of $99)

If you’ve already done all these, then you’re ready to go.

Getting Started

You should know from your app’s design and development stages,what devices you’re targeting, as this will have informs the design. Therefore, you should also know which resolutions and sizes you’ll need to create images and app icons. Refer back to your documentation if you can’t remember the specifics.

There are a number of configuration screens that you’ll need to complete when preparing your app for release.

You should also know which languages and countries your app will be available in, because the translations should either be included in the initial release, or planned for at a later stage in your production schedule.

The Developer Console

The Developer Console is the dashboard for setting up the information about your app and managing your App Store account.

There are many areas to the Developer Console. Once you have an account, make sure you explore all the areas, familiarizing yourself with what you can do and anything more you need to do to set up.

The section you’ll mostly work within when releasing your app is the My Apps section.

Every app you release to the store has an individual place in this section. Once you have created a new app in this area, you are ready to begin.

The details that make up your App Store page come directly from the App Store information you include here. And your App Store page only includes the information you include on these screens, so you need to be thorough. These details can be visible on your page—like the description, title, and screenshots—or work in the background—like keywords.

Double-check before you submit your app for review, as submissions from new developers could take up to a week to pass submission. If you have to make changes to this information, you have to start again from day one.

Configuring your App Information

Once you’re familiar with the Developer Console, you need to configure, and then add settings and the details for your app.

The details within the App Information section will be used across all devices that this app serves. Once your app is released, any changes you make to the App Information will be reflected in the next version of your app that you release.

Localizable Information

These are all of the details of your app that can be translated into languages other than your primary language.


This is the name that the buyer/consumer/customer will see on the App Store page. Making your app name easy to spell and related to the functionality of the app means that you’ll have less to explain about the main features of your app. A good example of this is Snapchat.

Ensure your app name isn’t longer than 50 characters. In fact, sometimes two short words are better than a single long word, as (from your testing) you’ll know that the words wrap. Overall though, one short word is the best option for a name.

Privacy Policy URL

This URL links to your privacy policy. You may not think you need one if this is just a hobby or you’re doing this for fun, and you may be right. But it all depends on your app’s target audience and content.

If you have any of the following features, or target these audiences, you need a privacy policy:

  • An app for children
  • If you offer free subscriptions
  • If you offer subscriptions that auto-renew
  • You allow account registrations
  • You access a user’s existing account

If you collect user- or device-related data, you are only recommended to have a privacy policy.

Primary Localised Language

This setting is very important, however it’s not subtitled, and your attention isn’t really drawn to it as it is with other sections on this screen.

You can also set your primary localised languages here via a drop down.

General Information

Bundle ID

This is the ID that you used in Xcode. Be aware, it can’t be changed after you upload your first build. So get it right!

You have the option to register a new ID or chose the iOS Wildcard App ID option. You usually use the wildcard option for apps that don’t use app-specific functions like in-app purchasing or Game Center. You can read more about Wildcards App Ids in the Apple Developer library.


This is a unique identifier for your app. Don’t worry, it’s not visible on the Store so you can use any obscure ID you wish. Just make sure you keep a note of it if it’s that unusual.

Getting into the habit of creating SKUs in a specific format is a good idea, so that even if it’s not clear to someone outside of your team, you’ll be able to look at your SKU ID and know what it relates to without looking it up. For example, you may choose to use the first three letters of your app name in capitals, and then maybe the date it was first released. It’s really up to you.

Apple ID

This ID is automatically generated and assigned to your app. It’s arbitrary, so don’t try and make sense of it. But you may want to keep a note of it somewhere easily accessible. It’ll save you logging back into the app store and going to this page in order to find it.


Primary Language

This is simply a read-only text field set by the localizable primary language you already set. I know it’s confusing having language defined in two places, but it’s the way this screen is laid out at the moment.

You need to set up the primary language in which the app will be used. Additionally, you have to set up the languages for which the app will be localised.

If your localized language isn’t available, then the content served will be from the primary language.

If you can’t find a supported language you would like to use, see the FAQ.


Now you must define what category your app is best suited to.

What’s the main function of your app? Does it provide entertainment, improve your productivity, or make it easy to keep up with the activities of your favourite charity?

You could try and classify your app in a category that you know is popular in the hopes of it getting discovered, but this kind of classification may mean that those looking in the correct category for your app will miss it. It’s up to you to decide what’s more important.

If you’re not sure about what to choose or have other questions, you can see the App Store Category Definitions.

So, you’re analysing your app to see which category will suit it best. But what if you think it could fit into more than one? Well, you’re in luck. You have the option to assign a primary category and an optional secondary category.

The primary and secondary categories are currently as follows:

  • Books
  • Business
  • Catalogs
  • Education
  • Entertainment
  • Finance
  • Food & Drink
  • Games
  • Health & Fitness
  • Lifestyle
  • Magazines & Newspapers
  • Medical
  • Music
  • Navigation
  • News
  • Photo & Video
  • Productivity
  • Reference
  • Shopping
  • Social Networking
  • Sports
  • Stickers
  • Travel
  • Utilities
  • Weather

License Agreement

Here you can set Apple’s Standard License Agreement or edit it to best suit your project’s or team’s purpose. The License Agreement is in place to detail who has ownership of the product from the End User’s perspective, i.e., the person who downloads your app. This differs from the Privacy Policy, because in a privacy policy you as the developer define what you are doing with the information you gather through your app, in order to protect and enforce the rights of the users of your app. By contrast, the License Agreement arguably works more to protect the interests of the app developer.


An age rating is required, as it classifies the minimum age of the audience that can use your app. The age rating of the app is based on the most mature rating required across all devices.

The current list of age ratings that you can clarify your app under is as follows:

  • No Rating
  • 4+
  • 9+
  • 12+
  • 17+

Additional Information

This section allows you to preview your app and see how the details you have set up will look on the App Store.

It’s a good idea to see how the settings you have chosen are depicted and positioned on the App Store page before it goes live. For example, it could be that when you preview it, details in an image you’ve taken look a lot smaller and are only visible when you open the full size image. This may not be good for catching the eyes of those just browsing for a new app on their smart phones.

If you find something that looks incorrect, you can always go back and update the details, even after you submit your app for review.

What’s your next step?

So, now you have been introduced to the Apple Developer Dashboard. You have a basic understanding of how to configure the App Information screen in the My Apps section in order to start building an attractive and informative App Store page.

So now what do you do with this initial knowledge of the App Store? Why not build upon it?

There are still two more screens left to populate with information before you submit your app for review.

In my next post, I’ll share what information you need to supply on the next screens to build a great App Store page.

Instantiating uniquely named objects

So my first major hurdle in September left me stumped for ages.

Highlighting some of the challenges I faced when creating Project 1.


I was trying to instantiate a grid of button game objects. Whenever a button is pressed, the object is destroyed and after x seconds it’s recreated in the same position. I managed to get this working with a single object, but not a grid of them.


Nothing was getting recreated when I clicked a button in the grid.

I was giving every button in the grid the same name when it was instantiated. So when I tried to check if the object was destroyed there were obviously multiple more on screen so nothing would get recreated.

Tasks towards a solution

I needed to try to:

  1. Name each object individually!
  2. Check for each object to see if it was destroyed
  3. Recreate the destroyed object

Using the tag property

For task one, I tried tag every object, but learned that tags can only be created in the editor, are used mostly to group objects of the same type (like the same type of button) and they are static. They can’t be created dynamically from code.

Using the name property

Next, I tried to give each object an individual name using the Name property. This worked great. I used a variable to count how many objects were being created, then used that variable to construct a unique name for the object.

Task one solved!

Checking a list

For task two, I decided to create a list of the named objects. Then I looped through the list to see if any are found then return a bool of the result. I could then use this to decide whether to call the recreate object method. Nice idea, but unfortunately the way I called this method led to a loop of only seeing that the first object had been destroyed.

Back to the keyboard with that then.

Lessons learned

So far, these are my takeaways from my first challenge.

    • How to use tags appropriately
    • The Tag and Name properties of game objects


  • The difference between local position and world/global position.


Obviously, I need to overcome task two so I can focus on implementing the rest of the gameplay and releasing this as soon as possible.