Aim: Deploying all Apps in Particular App Store/Hosting
On the app store
- Is Your Application Ready?
Step 1: Testing
An application isn’t necessarily ready when you’ve written the last line of Code or implemented the final feature of the application’s specification.
Have you tested your application on one or more physical devices? Have you profiled your application for memory leaks and performance issues? Does your application crash from time to time?
The family of iOS devices has grown substantially over the years, and it is essential to test your application on as many iOS devices as you can lay your hands on. Common issues include not optimizing an application for specific screen sizes. An iOS Simulator is a great tool, but it runs on your Mac, which has more memory and processing power than the phone in your pocket.
Apple’s Review Process isn’t airtight, but it is very capable of identifying problems that might affect your application’s user experience. If your application crashes from time to time or it becomes slow after ten minutes of use, then you have some work to do before submitting it to the App Store.
Even if Apple’s review team doesn’t spot the problem, your users will. If the people using your application are not pleased, they will leave bad reviews on the App Store, which may harm sales or inhibit downloads.
Step 2: Rules and Guidelines
As I mentioned earlier, Apple provides developers with several documents that are a great help during the creation and development process of your application.
The documents you should be aware of are the iOS Human Interface Guidelines and the App Store Review Guidelines. Despite the availability of these documents, it seems that few developers take the time to browse them, let alone read them. It shouldn’t be a surprise that some applications are therefore rejected even though the reason for the rejection is clearly stated in these documents.
Even if you don’t intend to read the iOS Human Interface Guidelines or the App Store Review Guidelines, it is essential to know some of the rules that they talk about. Take a look at the shortlist below to get an idea of what your application should and shouldn’t do.
- shouldn’t crash
- shouldn’t use private APIs
- shouldn’t replicate the functionality of native applications
- should use In-App Purchase for in-app (financial) transactions
- shouldn’t use the camera or microphone without the user’s knowledge
- should only use artwork that is your copyright or that you have permission to use
Keep in mind that this is a tiny subset of the guidelines included in the documents mentioned above. The majority of the rules and guidelines are trivial, but some are not, and you might even violate some of them inadvertently.
Let me give you an example. Before Apple started using its maps (a really long time ago), the MapKit framework used Google’s maps. This was clear to the user because of the small Google logo in the bottom left corner of each map. However, if some part of your application’s user interface covered or obscured Google’s logo, your application would get rejected. This rule seems trivial, but it is a rule that is easily violated if you’re not careful. Even automated tests won’t cover you in this case.
Before you can even start thinking about submitting your application to the App Store, you need to make sure that you have an App ID, a valid distribution certificate, and a valid provisioning profile. Let me show you what this entails.
Step 1: App ID
Every application needs an App ID or application identifier. There are two types of application identifiers: an explicit App ID and a wildcard App ID. A wildcard App ID can be used for building and installing multiple applications. Despite the convenience of a wildcard App ID, an explicit App ID is required if your application uses iCloud or makes use of other iOS features, such as Game Center, Apple Push Notifications, or In-App Purchase.
Step 2: Distribution Certificate
To apply to the App Store, you need to create an iOS provisioning profile for distribution. To make such a provisioning profile, you first need to create a distribution certificate. The process for creating a distribution certificate is very similar to creating a development certificate. If you have tested your application on a physical device, then you are probably already familiar with the creation of a development certificate.
If you need to refresh your memory, I suggest reading Apple’s guide, Code Signing your Apps, about signing certificates and provisioning profiles. The process is not complicated once you understand how the various pieces of the puzzle fit together.
Step 3: Provisioning Profile
Once you’ve created an App ID and a distribution certificate, you can create an iOS provisioning profile for distributing your application through the App Store.
Keep in mind that you cannot use the same provisioning profile that you use for ad hoc distribution. You need to create a separate provisioning profile for App Store distribution. If you use a wildcard App ID for your project, then you can use the same provisioning profile for multiple applications.
Step 4: Build Settings
With the App ID, distribution certificate, and provisioning profile in place, it is time to configure your target’s build settings in Xcode. This means selecting the target from the list of targets in Xcode’s Project Navigator, opening the Build Settings tab at the top, and updating the settings in the Signing section. You will need to set the Code Signing to Automatic.
Even though the code signing process is fairly simple once you understand it, it is something that trips up a lot of developers. I don’t know a single Cocoa developer who hasn’t run into code signing issues at some point in their career. Once you’ve cleared this hurdle, the rest of the submission process is fairly easy.
Step 5: Deployment Target
It is useful to think a little about your application’s deployment target. Each target in an Xcode project has a deployment target, which indicates the minimum version of the operating system that the application can run on.
It is up to you to set the deployment target, but keep in mind that modifying the deployment target is not something you can do without consequences once your application is in the App Store. If you increase the deployment target for an update of your application, then users who have already purchased your application but don’t meet the new deployment target cannot run the update.
It gets really problematic when a user downloads an update through iTunes (not the device), replacing the previous version on their computer, and then discovers that the new update doesn’t run on their device.
Step 1: Icons
You probably know that an application icon is a vital component of every iOS application, but you need to make sure that your application ships with the correct sizes of the artwork. Take a look at the table below:
It goes without saying that you don’t need to include an application icon for the iPad/iPad Mini device family if your application only targets the iPhone/iPod Touch device family, and vice versa.
Step 2: Screenshots
Each application can have up to five screenshots and three previews, and you must provide at least one. If you are developing a universal application, then you need to provide separate screenshots for each device.
It is important to spend some time thinking about the screenshots. Your application’s screenshots are often the only thing that a customer can use to decide whether to purchase or download your application or not.
What a lot of developers don’t know is that the screenshots don’t have to be actual screenshots. The hard rule is that the size of each screenshot needs to be that of the screen size of the target device. Many companies are creative with this rule. Take a look at the screenshots of Where’s My Water?, for example, which include labels highlighting key features of the app. By using this strategy, you can make screenshots much more attractive and compelling.
Step 3: Metadata
Before you submit your application, it is a good idea to have your application’s metadata at hand. This includes:
- your application’s name
- the version number
- the primary (and an optional secondary) category
- a concise description
- a support URL
If you are submitting an update, then you can also provide information for the What’s New in this Version section.
Does your application require users to sign in? Then you also need to provide Apple with a test or demo account to make sure that the review team can immediately sign in and use your application without first having to sign up for an account.
4. Submission Preparation
The submission process has become much easier these days. You can now validate and submit an application using Xcode, for example. First, however, you need to create your application in iTunes Connect.
Visit iTunes Connect, sign in with your iOS developer account, and click Manage Your Apps on the right. Click the Add New App in the top left, select iOS App, and fill out the form.
Step 1: Basic Information
The App Name, which needs to be unique, is the name of your application as it will appear in the App Store. This can be different than the name that is displayed below your application icon on the home screen, but it is recommended to choose the same name.
The SKU Number is a unique string that identifies your application. I usually use the application’s bundle identifier.
The last piece of information is the Bundle ID of your application. This means selecting the (wildcard or explicit) App ID that you created earlier from the drop-down menu.
Step 2: Price and Availability
In the next step, you specify your application’s price and availability. Apple works with price tiers so that you don’t have to specify a price for each country that Apple operates in. You can also specify in which stores your application should—or shouldn’t—be available.
The information that you enter in this step can be modified once your application is live in the App Store. In other words, you can change the price and availability of an application without having to submit an update. You can easily do this by selecting the Pricing and Availability tab on the left of your app’s iTunes Connect page
Step 3: Metadata
We’ve already covered the application’s metadata. The only aspect that I haven’t talked about yet is your application’s rating. Based on your application’s content and functionality, it is given a rating. This rating is not only useful for telling users about your application’s content and features, but is also used by the operating system for the parental controls features.
It is strongly recommended that you don’t try to outsmart the rating system. Apple is well aware of this strategy and will reject your application if it doesn’t agree with the rating that you have set. There are many other things here that you may need to adjust based on your app, but we won’t go over them since they are pretty self-explanatory. To do this, go to the App Information tab in the left pane.
5. Uploading the App Binary
To submit your app, you need to create an archive. You can only create an archive by building your application on a generic device. If you select the iOS Simulator in the active scheme, you will notice that the Archive option in Xcode’s Product menu is grayed out. Connect an iOS device to your Mac, select it in the active scheme, and select Archive from Xcode’s Product menu.
If the submission process went without problems, your application’s status will change to Waiting for Review. It takes several days for Apple to review your app, and the time it takes tends to fluctuate over time.