How to Submit an iOS App to the App Store

You have worked weeks or months on your first iOS application, and you are ready to submit your masterpiece to Apple's App Store. How do you do this? Is your application ready for submission? I am sure that some of these questions have entered your mind at one point or another. 

Is submitting an application as simple as sending Apple your application's binary? Not quite. With this tutorial, I will provide you with a detailed map to get your application submitted to Apple's App Store.

Introduction

Even though the App Store review process is a black box for the most part, that doesn't mean that you can't prepare yourself and your application for Apple's review process. Apple provides guidelines to help you stay within the sometimes invisible boundaries of what is and isn't allowed in the App Store.

The first time you submit an application to the App Store is exciting and nerve-racking at the same time. Even for experienced iOS developers, submitting an application to the App Store is often a stressful undertaking because it is something that most developers don't do on a daily basis.

Throughout this article, I am assuming that you are a registered iOS developer, which means that you are enrolled in Apple's iOS Developer Program and are allowed to submit applications for publication in the App Store. To submit an iOS application to the App Store, you need to be a registered iOS developer. Red flag? Don't worry. You can enroll in Apple's iOS Developer Program by visiting the Apple Developer page and clicking the Enroll button. 

1. 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 important to test your application on as many iOS devices as you can lay your hands on. Common issues include not optimizing an application for certain screen sizes. The 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 a number of documents that are a great help during the creation and development process of your application. 

The documents that 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 important to know some of the rules that they talk about. Take a look at the short list below to get an idea of what your application should and shouldn't do.

Your application:

• 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 aforementioned documents. 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 own 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.

2. Prerequisites

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.

If you're not sure what App ID best fits your project, then I recommend reading Technical Note QA1713 for more information about the topic.

Step 2: Distribution Certificate

To submit an application to the App Store, you need to create an iOS provisioning profile for distribution. To create 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 difficult 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.

I have two very simple tips with regards to your application's deployment target:

1. Be very careful when you decide to increase the deployment target of an existing application. Mention this in the application's release notes of the updates that precede the change, and again in the update that uses the new deployment target. If you warn your customers well in advance, you have done all you can to prevent potential problems. 
2. For new applications, I almost always set the deployment target to the last major release.

3. Assets

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
• keywords
• 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 all went well, you should now have an archive, and Xcode's Organizer should automatically open and show you the archive you just created. 

Select the archive from the list and click the Upload to App Store... button on the right. The application binary is then uploaded to Apple's servers. 

During this process, your application is also validated. If an error occurs during the validation, the submission process will fail. The validation process is very useful as it will tell you if there is something wrong with your application binary that would otherwise result in a rejection by the App Store review team.

6. Waiting

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.

Good luck!

Conclusion

The submission process is quite lengthy for a new application, but submitting an update to the App Store is much less cumbersome. Keep in mind that the submission process is much more involved if your application is localized in various languages as your application's metadata needs to be localized as well. However, localizing your application is well worth the effort as it often results in higher sales and positive customer feedback.

If you want to learn more about Swift and iOS development, check out some of our in-depth courses here at Envato Tuts+.

• iOS
  Go Further With Swift: Animation, Networking, and Custom Controls
  Markus Mühlberger
• Swift
  Code a Side-Scrolling Game With Swift 3 and SpriteKit
  Derek Jensen
• Swift
  Create iOS Apps With Swift 3
  Markus Mühlberger