So you want to be an iPhone developer. It’s actually not difficult to get started. The barrier of entry to becoming an independent app publisher has never been so low and the demand for good iOS developers is quite high.

There are over 400,000,000 people that have credit cards registered with Apple that could potentially buy your app. So want to get started?

This article is about downloading and getting a basic understanding of Xcode, Apple’s integrated development environment (IDE) for Mac, iPhone, iPod, and iPad.

Here is a summary of this article.

• Overview of Xcode and how to get it
• Creating an app from a template
• Running an app in the iPhone simulator
• Getting familiar with the user interface
• Important project, target, configuration and scheme settings that you must know about
• How to run the LLDB and GDB debuggers
• How to launch Instruments to profile an app
• How to run the static code analyzer
• How to create an App ID and Provisioning profile in the Provisioning Portal
• How to add an app to iTunes Connect
• How to archive and publishing an app

This article will be creating a new app from one of Apple’s templates. However, since the objective of this article is to get to know Xcode, I will not be discussing the details of the app code. This article does not discuss how to use Interface builder to work with xib or storyboards. The sample app is only created to have a project in Xcode to discuss.

The amount of detail about how to configure and use Xcode may seem overwhelimg at first. But after digesting this information the experience of developing in Xcode can become pleasant and sometimes even fun.

What is Xcode?

Xcode is Apple’s complete toolset that enables designing, implementing, testing and publishing iPhone, iPad, iPod and Mac apps and is free to download.

At the time of this writeup, if you are running Snow Leopard then, Xcode 4.2. is the latest version and if you are running Lion, then Xcode 4.3.3 is the latest version.

Xcode is comprised of several coupled components. These components are mostly integrated into a single application window that streamlines doing many different tasks in the Xcode app.

In the single window Xcode app you can:

• Create a new project
• Write code
• Implement and manage Git or SVN source control
• Graphically deign an apps user interface using Interface builder
• Manage project settings, build settings, resources, frameworks, etc
• Run your app on the iPhone or iPad simulator or on a physical iPad, iPod, or iPad
• Statically analyze your source code
• Profile your app with Instruments
• Debug your app with LLDB or GDB debugger
• Archive your app for distribution
• Submit your app to the Apple App Store using Organizer
• and much more

How to get Xcode

Before you can download Xcode, you will need to complete the free registration for the Apple Developer Program by clicking here.

While Xcode 3 and Xcode 4 are both currently available, I strongly recommend getting Xcode 4. This article only will only provide an overview of Xcode 4. Both Xcode 3 and Xcode 4 can use the latest iOS SDK libraries.

After a challenging transition from Xcode 3 to the completely redesigned Xcode 4, I am very glad I migrated because Xcode 4 in my opinion is a much better product in that Xcode 4 has a lot of cool features that are not available in Xcode 3. The built in git source control, code compare and the general organization of project, build and configuration settings are some of the things I like better about Xcode4 over Xcode3.

There are two ways to download XCode. The easier way to get Xcode is probably by using the Mac App Store app that is built into your Mac.

The second way to get Xcode (after you have registered to be an Apple developer) is to logon to the Apple Developer Site (http://developer.apple.com) and manually download and install the Xcode app package.

When I first started using XCode, the Mac App Store did not exist. After the Mac App Store became active, I tried using the Mac App Store to upgrade Xcode. For some Xcode upgrades it has worked great and for others there have been some minor glitches, like the Dock icon did not get updated and I had to manually replace it to point to the new version of Xcode.

Even if you use the Mac App Store app to get Xcode, it is a good idea to download the Xcode app package from the Apple Developer Site and archive it if for some reason you might want to roll back to a previous version of Xcode. This probably will not be necessary for most people, but I like to do it as a safeguard in the event that a new version of Xcode does not meet my requirements.

Installing Xcode

After getting Xcode, you will want to select which tools to install. You can add just the iOS development tools or both iOS and Mac development tools. I chose to install both because I do some Mac programming too.

Running Xcode for the first time

The first time that you run Xcode you will be presented with a splash screen that says Welcome to Xcode like the one shown here.

Since this blog is primary focused on creating games, lets create an app that is the foundation for most games, an OpenGL ES based app.

The following numbered steps are the process for creating a new application using a built in Xcode template for creating an OpenGL ES based app.

1) Click on Create a New Xcode project in the Welcome to Xcode dialog.

2) A dialog titled Choose a template for your new project will appear. On the left under iOS click on Application and then towards the right click on OpenGL Game. Click next.

3) You should now see the Choose options for your new project dialog that is shown in an image below. Enter SampleOpenGLApp for the Product name, your com.companyName Company Identifier, and ensure that there is a check mark next to the Use Automatic Reference Counting to enable ARC for this app.

Details about the Choose options for your new project dialog – The Product Name and Company Identifier are combined to form a reverse domain name used by apple to uniquely identify an application. For the product name choose something like SampleOpenGLApp with no spaces in the name. For the Company Identifier enter your company identifier. For Heyalda this is entered as com.heyalda.

For the Class Prefix you can enter a prefix that will be added to all new classes that you create. This is nice so that if you name a class similar to an existing public api, you will not end up have a serious problem with having duplicate
symbols in your project.

Automatic Reference Counting is a feature that Apple added recently that simplifies the amount of code that you have to write to do memory management as well as improves memory management performance. Apple recommends using it and so do I because it reduces the amount of code I have to write.

Storyboard is apples graphical layout tool, mostly for graphically laying out UIKit objects. I don’t use UIKit objects much in my OpenGL games, and when I do I just create them programmatically. Interface builder and Storyboards are great tools for creating lots of types of apps, but for the type of OpenGL games that I create it is not very useful.

Unit Tests are a good way to build into your app the ability to create code that tests your code. I will not cover the use of unit tests in this article. Click next.

4) In the dialog to save your newly created app, I suggest creating a new folder in a convenient location of your choice, such as the Documents directory. Here you can also choose to have Xcode automatically create a local Git source control repository. While you can manually add Git later via command line, I prefer to add it here and then do regular commits of my code so that I can easily track changes use the built in side-by-side source code compare feature in Xcode 4. Click Create to create your new app and save it to your selected location.

You should now see the newly created project.

5) Click on the drop down list box in the top left corner of the Xcode app and choose iPhone 5.1 Simulator.

6) Click on the Run button in the upper left corner of the Xcode application. You should see the project build without any error and then Xcode will launch the iPhone Simulator and run your newly created application. The image below shows the newly crated app that you should see running.

After clicking on the Run button, the app will build and be installed on the iPhone Simulator. This app does not respond to touches, but try clicking on the iPhone simulator screen while holding down the Option key on a Mac or the Alt key if you have a non-Mac keyboard. You will notice that you can simulate two fingers touching the screen at once to simulating pinching and rotating two fingers. You can then hold down the shit key at the same time and simulate two fingers touching and swiping.

Click the Stop button in the upper left corner of the Xcode app. This will stop the simulator.

Now lets take a closer look at the Simulator.

Overview of the Simulator

Apple provides a sleek simulator for testing some aspects of iPhone, iPod, and iPad apps. If you have been following along so far, you just saw it in action. The simulator behaves just like an iPad or iPod, with some very important exceptions around performance (RAM and CPU capabilities), audio i/o, graphics rendering. The simulator works great for lots of purposes, but it is important to also test your apps on all hardware devices that you plan to support.

The Simulator Menu

Click on the simulator to activate the Mac menu on the top of your screen for the simulator. Browse through all the menu options. You can change the hardware for iPhone and iPad to simulate a retina or non-retina display, simulate memory warnings, change the version of the simulator to an older iOS version if you have one installed, rotate the device, and several other useful features.

The Simulator App Install Location

One cool feature of the Simulator is that you can view and manipulate data in the app install location. This is useful if your app creates data and you want to inspect data that has for example been written to the Documents directory. Xcode installs your apps on your file system for the Simulator to use in the following directory.

/Users/YOUR_NAME/Library/Application Support/iPhone Simulator

Because the Library is a hidden directory, you will not be able to browse to this location in finder. To make the Library folder visible you can execute the following in the Terminal app that can be found by clicking on Applications on your Dock and then on Utilities and then on Terminal.app.

In the terminal app, enter the following and then press enter.

defaults write com.apple.Finder AppleShowAllFiles TRUE

Now enter this next line and press enter. This will close all open Finder windows.

killall Finder

Now open Finder and browse to: /Users/YOUR_NAME/Library/Application Support/iPhone Simulator

You can then drag this folder into your favorites on the left side of your finder so that it will be available when you want to view files that your app is manipulating.

If your are like me, you will not like the extra clutter of seeing all the hidden files and folders, so you can now hide them again by using the terminal app, enter the following and then press enter.

defaults write com.apple.Finder AppleShowAllFiles FALSE


Now enter this next line and press enter. This will close all open Finder windows.

killall Finder

The /Users/YOUR_NAME/Library/Application Support/iPhone Simulator directory contains the target iOS SDK version number of the app build. So all of your 5.1 apps will be in the 5.1 folder. You will have to look into the numbered folder, here it should be 5.1, and then the Applications folder and then you will see the cryptic sandbox folders that each app is installed in. Browse to find the numbered folder that contains the desired app name, in this example it is SampleOpenGLApp.app, in order to find the desired Documents and tmp folders.

Deleting Apps from the Simulator

You can delete apps from the simulator the same way that you would delete apps on an iPhone, iPad, or iPod. Click-and-hold on the app you want to delete with your mouse and then click on the little X that appears next to the app you want to delete. Note that this will delete the sandboxed folder and any data that is in the Documents directory, just like if you deleted an app off of a device.

An alternative way to delete an app from the simulator is to delete the sandbox folder for the app.

Overview of the Xcode 4 user interface

There are a lot of details to understand when configuring an app for testing and eventually archiving it and uploading it to the app store. I will now attempt to cover the aspects and settings that are important to know to build, test, archive, and publish an app.

The Navigators

The left side of the Xcode app is the default location of what are called navigators. Sometimes you may accidentally hide the navigator. If this happens, in the main menu of Xcode go to View -> Navigators -> Show Project Navigator to get them back. If the Run button and entire toolbar are not visible, you can click on View -> Show Toolbar to get the toolbar back.

The following types of navigators exist.

• Project – Very useful. Shows a list of folder groups and folder references of class files and resource for the project.
• Symbol – Have not needed to use this much. Shows the symbols that are used in your app.
• Search – Very useful. Used to search through class files and resources in your project.
• Issue – Very useful. Shows static analyze and build warnings and errors.
• Debug – Very useful. When debugging an app, shows the symbol call tree and some other useful stuff.
• Breakpoint – Shows a list of breakpoints that are currently defined in your project.
• Log – Shows the list of console logs from previous runs of your app.

Changing Views

In the upper right corner by default there exists eight buttons. These buttons are shown here in the following image.

On the left side there is the three Editor buttons. Starting from left to right, the first button sets the standard editor view that you will use most of the time. Alternative views are the next two buttons. The tuxedo looking button changes the view to the assistant editor which enables viewing the interface .h file and the implementation .m file side by side. The third button sets the code compare view that enables a two column view to compare your currently selected class to previous git source control commit.

In the middle is the three View buttons. From left to right the first button enables visibility of the navigator on the left. The second button toggles visibility of the console log and debug info on the bottom of the app, and the third button toggles visibility a properties/utilities view on the right of the screen.

The most useful aspect of the properties/utilities side view that I have found is identifying and changing if a class file or resource is part of a target or not. Try clicking on a .m implementation class file and then enable the utility side view. You might have to scroll up or down to see it, but there is a section titled Target Membership. This is really useful to check which target a resource or class implementation file belongs to. For example, you might see an image file or audio file in your project navigator, but when you run your app if it is not part of a target then it will not be copied into the app bundle, and as a result your app code will not be able to load the resource.

The Organizer button launches the Organizer. The Organizer will be discussed later in this article.

The double arrow at a 45-degree angle in the upper right corner is the full screen view button.

Project Settings

Xcode 4 enables having settings that apply to the entire project and also settings that only apply to specific targets. To view the project settings, click on the app name at the top of the project navigator view. You should then see something similar to the following image. However, I have added a second target to this project as well as duplicated the Release configuration and named the copied configuration with the name Distribution.

It is a good idea to always create a Distribution target for apps you intend to publish. Then in your build settings you can configure the code signing of the Distribution target to be the App Store distribution provisioning profile and the code signing for Release configuration can be set to the test provisioning profile or an ad hoc provisioning profile. It is important to ensure then that any settings you change for the release are also applied to the Distribution configuration so that the only difference between the Release and Distribution configurations are the code signing. You could even wait to copy the release configuration until you have configured it for what you think will be a stable setting and then copy it and create the Distribution configuration with the correct code signing.

One other important thing to note is that you can configure build settings for the project, but the target build settings can override the project build settings.

Target Settings

Target settings are settings that apply only to a specific target.

What is a Target?

A target is basically a specific build of an app. Most of the time I have applied settings at the target level. For example, you might decide to create a free version and a paid version of your app. A simple way to do this is to right click on your existing target and click duplicate. This will create a duplicate of the original target. You can then click slowly on the copied target name twice to highlight it and then rename it to something appropriate, such as SampleOpenGLApp-Free.

What is a Configuration?

Each target can have multiple configurations. The two default configurations are Debug and Release. The primary purpose of these configurations is to enable making small changes when building a specific target, such as enabling or disabling the debugger. Another common example is to define NDEBUG and NS_BLOCK_ASSERTIONS=1 as pre processor macros in your Release and Distribution code so that Assertions are not thrown in code you publish.

Code signing is another type of change that fits well into being defined at a configuration level. As mentioned above, for all of the apps that I create, after I have setup the Release configuration for a project I duplicate it and call the new copy Distribution. I then change the code signing in the Distribution configuration so that it uses the provisioning profile for Apple App store distribution. It is also necessary to change the Archive scheme setting (discussed below) to use this configuration for the specific target (more information about that is provided below in the Schemes section of this article.

Summary Tab

The summary tab is visible when you have a specific target selected. The summary settings are specific to each target. Here you can set the version number, app identifier, iOS version deployment target, the specific icon and splash screens for iPhone/iPod app as well as iPad apps, and any entitlements that your app will utilize, such as iCloud entitlements.

Info Tab

The Info tab displays the info.plist property list file for the specific target that is selected. Here you may want to update the desired device capabilities so that your app will only run on certain devices that have the required capabilities. The info.plist file name can be changed and the specific name is defined in the build settings for each target as the Info.plist File property. Each configuration within each target can optionally have a different info.plist file.

Build Settings Tab

The build settings for each target contain a lot of preprocessor and compiler settings. The following are some that I think are important to understand.

Compiler for C/C++/Objective-C – The default compiler at the time of this writeup is Apple LLVM compiler 3.0. You can alternatively choose to use the LLVM only for the code preprocessor and use GCC 4.2 for the compiler if for some reason you have a need for GCC 4.2.

Code Signing Identity – You must set this to your iOS Team Provisioning Profile or some other valid provisioning profile in order to test your app on a physical device. You also must assign a distribution profile to a release or distribution Scheme in order to publish an app either ad hoc or via the Apple App Store.

User Defined Settings – User defined settings enable defining specific things for each target. For example, if you click on Add Build Setting in the bottom right corner of the build settings and add a user defined build settings you could then add something like FREE_VERSION and assign it the YES value. Then in the app you can use the #ifdef preprocessor commands in your app to add conditional build code to alter the build so that one target will build a normal version of your app and one target will build a paid version of your app.

iOS Deployment Target – While this is a setting that can more easily be set in the Summery tab, it is worth noting that this is the minimum iOS version that your app will run on. So if you wanted to set this to 4.0, then you app would be available to run on devices that meet your required device capabilities from the Info tab and have at least iOS 4.0. You should of course have to test on all major versions from 4.0 to the current version to ensure your app behaves as expected.

Base SDK – This is the software development kit that will be used to build and package your app. This is different from the iOS Deployment Target version. It is a good idea to have the latest version of the iOS SDK before publishing your app and set the Base SDK to that version. The default setting is Latest Version, so it should automatically set this to the most recent version you have installed.

Build Phases Tab

The Build Phases Tab is primary used to configure library linking and enables reviewing which resources will be added to a build.

The two most useful features in the Build Phases Tab are the Link Binary with Libraries and the Copy Bundle Resources.

The Link Binary with Libraries enables adding specific frameworks or libraries to your app. For example, if you wanted to add Game Center, you would go to this tab, expand the Link Binary with Libraries and then click the small plus sign in the bottom left corner and select the GameKit.framework to add it to the currently selected target. It is important to note that this only adds it to the currently selected target. It also strangely adds it to the top of your project navigator view. After adding a framework, drag it down to the Frameworks group folder and then check the target membership in the utility side view discussed in the changing view section above. If you have multiple target, you can choose which target binaries the framework should linked to.

The Copy Bundle Resources allows reviewing all of the resources that will be added to your app bundle when it is packaged. This is a semi-useful way of reviewing your resource bundle before packaging your app.

Build Rules Tab

For the 38 apps I have published, I have yet to have a need to use features covered in this tab.

Schemes

Schemes are used to manage which target configurations to use in specific scenarios. The scenarios for each Scheme are run, test, profile, analyze and archive. I am not sure if scenario is the official name for these, but calling them scenarios seems to make sense to me.

In the Xcode menu, you can click on Product -> Manage Schemes to view the projects schemes. Scheme names are auto created from the target names, so if you want to change their names you can change the target names, delete the schemes in the scheme manager and then auto create new schemes. In the scheme manager you can double-click on a scheme name to view the scheme details. It is here that you will want to set which build configuration is used in each scenario. Here you can also set if you want to use LLDB or GDB or no debugger for a particular scenario.

If you are not using unit tests and advanced diagnostics, then the Run and Archive scenarios are the most important to you.

The Archive scenario should be set to the build configuration that has the desired distribution code signing. I set this to the Distribution configuration that I created in the Project Settings section above.

For the Run scenario, I initially set this with a configuration of Debug and change between the LLDB and GDB debuggers as needed. After the project becomes more mature, I change the Run scenario to use the Release build configuration and disable the debugger by selecting None from the drop-down list box to select the debugger.

When running your app from using the toolbar, if you hold down the Run button a list box will pop up and you can choose which scenario of a specific scheme to execute. The options are Run, Test, Profile, and Analyze which map back to those defined in for each Scheme.

Debugging an App

Xcode comes with two awesome debuggers, LLDB and GDB. You can enable the debugger for a particular scheme that you are running in the Scheme editor described above. After enabling the LLDB or GDB debugger, one thing you can do is set break points in your app. Try it out. In the project navigator, open the folder group titled SampleOpenGLApp or whatever you named the sample app. Click on the AppDelegate.m file. This file might have a prefix on the front of it if you defined one when creating this project.

In the AppDelegate.m class implementation file, add a break point by clicking on the line number next to one of the lines in the application:didFinishLaunchingWithOptions: selector. In the following image, this was done on line 29.

You should see a blue bar appear over the line number. This is setting a debug break point.

Ensure that your Run Scheme has the Debug configuration selected and either the LLDB or GDB debugger selected. If yo do not have this setup, and you run the app, the debugger will not stop the code execution at the breakpoints.

Click the Run button.

The app should compile without any errors and then when it starts it should stop at the debug break point you set in the AppDelegate.m class file.

You can set breakpoints like this anywhere in your app. If you hover over the object pointers in the code you will be able to see information popup about the state of the objects.

On the left side you see the threads that are active and where in the call tree the app was interrupted.

On the toolbar at the bottom of the class editor view and above the debug area there are small buttons. These control the debug flow. You can press the play button to continue the app execution, the the down arrow to step to the next line of code (next line might actually be lower level library code or even assembler sometimes).

The Three view buttons to the right side of the toolbar are worth mentioning. Try clicking on them to see how they change the debug view. The default is not to show the console debug log output and only show the values assigned to the variables, which is equivalent to clicking on the left most view button. The middle view button shows both variables and the console output, and the right most view button only shows the debug log console output.

Debugging an app involves a lot more than just setting break points. The purpose of this section is to show you how to get started with debugging an app.

Profiling an App

Profiling enables running an app on the device or in the simulator and measuring performance related aspects of the app as well as testing for bad code that is causing memory leaks or zombies to be created. It is important to assess the performance and memory management behavior of an app before publishing. It is also a good practice to periodically utilize Instruments during the development of an app to catch problems and deal with them sooner than later.

If you click and hold on the Run button and then select Profile, you will build your app and if it builds with no errors then the Instruments app will launch. The following image shows the dialog Instruments presents after choosing to profile your app.

Instruments provides several templates that enable profiling your app to identify things like if your app has any memory leaks, zombies, or how time efficient certain modules of your code are.

To see Instruments in action, try selecting the Leaks template and then click profile.

You can then enable or disable automatic snapshots or change the frequency of when snapshots are taken. Each snapshot effectively checks to see if any memory has been leaked.

In the upper left corner you can click on Leaks and this will then change the details table below to show what objects were leaked and what code was responsible.

On the top center of the Instruments app try clicking on the third button above the title View to enable the right side drill down view.

Now click on one of the leaked objects and you can drill down into the code to see what caused the leak.

I am not sure why this sample is leaking so much memory (at the time of this writeup). Maybe it is because it is being run in the simulator but this is just a wild guess and I do not have the time right now to dig deeper into what is causing the leak. I did, however, click on the object that is leaking most and then drilled down on the right hand side view as described above. Below is an image showing the line of code that Instruments says is causing the leak. The variable titled effect is of the type GLKBaseEffect and has the strong ARC property setting. When it is created it is created like this.

self.effect = [[GLKBaseEffect alloc] init];

The line of code that Instruments says is causing the leak is on line 230 of the HeyaldaViewController.m class and is the following.

// Render the object with GLKit
[self.effect prepareToDraw];

In a future post I might provide more details about how to use specific templates within Instruments.

Static Analyzer

The static analyzer tool that is built into Xcode is a great way to quickly analyze the static code of your project to identify potential issues. You can run the static analyzer by clicking and holding down the run button in Xcode and then select Analyze. After the static code analyzer completes, click on the triangle with an explanation mark in it at the top of the navigators panel on the left side of Xcode to view the output of the static analyzer. This is the same location where compile warnings and error are displayed. Review the results and take appropriate action to fix any issues that were identified.

Getting Ready to Publish an App

Before you can publish an app, you will need to create an App ID, provisioning profile, and an iTunes Connect profile for your app and change the status of your app in iTunes Connect to Waiting For Upload.

This section provides the the step-by-step process for creating an App ID and provisioning profile and then walks through the process of creating a profile for an app in iTunes Connect.

Creating a new App ID and provisioning profile

1) In a web browser go to http://developer.apple.com, click on iOS Dev Center, login with your developer account credentials, click on iOS Provisioning Portal, click on App IDs and then create a new App ID for the app you desire to publish.

2) After creating the new App ID, in the Provisioning Portal, click on Provisioning and then click on the Distribution tab and then click on the New Profile button.

3) Select if the app is being distributed via ad hoc or though the Apple App Store. Enter a profile name for your reference and then select the same App ID you created above.

4) If the app is for ad-hoc distribution select the devices that you previously setup as part of your total of the 100 ad hoc devices you can distribute to.

5) Click the Submit button.

6) Click on the distribution tab again. If the status of your provisioning profile is not active, wait several seconds and then click on the distribution tab again.

7) When the stats of your provisioning profile becomes active, download it and then drag it onto the Xcode icon in your Dock.

Creating a new iTunes Connect App Profile

I recommend using the current version of the Safari web browser when creating your app profile in iTunes connect. For some reason, when I have used the current version of Firefox to create a new app profile the drop down list boxes to select the primary and secondary app category do not function correctly.

1) Logon to iTunes connect with your developer account credentials.

2) Select the default language that you would prefer to use to manage this app in iTunes connect.

3) Enter the unique App name that you have the right to use. It can be up to 255 characters long.

4) Select the bundle ID that you created in the provisioning portal for this app.

5) Click continue.

6) Select the date that you desire your app to become available in the Apple App Store. If your app is not approved by Apple’s app review team before this date, then it will be released after Apple approves your app. You can also select if you want to provide a discount to educational institutions and if this app will be sold using Apple’s B2B selling platform.

7) Enter the version number for this App. This version number should be set to match the version number you assigned in the application settings for the specific target. Here you also must enter the copyright ownership of the app and the primary category of the app. It is a good idea to also add a secondary category for your app if one is applicable.

8) Each app must have an age rating assigned to it. To assign an age rating, select the radio buttons next to each content category based on what content is in your app. The age rating will automatically update the radio buttons based on what content is in your app.

9) Enter a description, key words, support email and marketing and support websites for your app. You can also add a link to a privacy policy.

10) To save your app you must upload a 512×512 png or jpg file for the app icon and one 960 x 640 or 640 x 960 pixel iPhone screenshot or one 2048 x 1536 or 1536 x 2048 iPad screenshot. The screenshot images do not need to be just a screenshot of your app. They should market your app but also accurately convey what it is that someone will be downloading. You can and should add five iPad and five iPhone images. The icon image can be updated until the app is approved by apple. After that, you need to create a new version and submit it to app for review to change the icon image. The screenshot images can be updated at any time, even after your app is live in the Apple App Store.

11) After saving your newly created app, you can take up to 120 days to configure Game Center, In App Purchase, App Store Language Localization, and other settings in iTunes Connect as you build your app.

12) When you are ready to upload your app, the next step is to click on the blue Ready to Upload Binary button shown in the following image. It should be noted that after you submit your app to Apple and they approve it, you cannot change the App icon, app name, key words, add localization descriptions for additional countries, and several other details about your app unless you create a new version and upload that app for review. It is a good idea to review the iTunes Connect FAQs page by clicking on the link at the bottom of iTunes Connect web application and check out under Manage Your Applications link to see the details of the different statuses an app can be in and what you can and cannot do during each app status.

13) An important legal issue is determining if your app uses cryptography and if so does it comply with the applicable laws relating to selling and exporting an application that uses cryptography.

14) Click continue and you should be ready to upload your archived app to the Apple App Store.

In the following image you can see that the status of the app has changed from Preparing for Upload to Waiting For Upload. This indicates that you can now use the Organizer to upload your app to the Apple App Store.

Archiving and Publishing an App

Archiving an app is a necessary step before you can publish it to the Apple App Store or distribute it via ad hoc or within your company if you have an enterprise developer agreement with Apple.

The first thing to check is that the bundle identifier, bundle display name, and other app info settings are as desired. To do this, click on the target of the app and then click on the info tab.

I needed to overwrite the Bundle identifier and Bundle display name with the settings shown in the following image. Note that the Bundle display name is the name that will be seen under the icon of your app when it is installed on an iPhone, iPod, or iPad.

You should also review the other settings here to verify that the values are as you intend them to be.

Next review the scheme settings for the target that will be archived and ensure that the configuration in the scheme for the Archive scenario has the correct code signing assigned to it in the build settings of the target.

For example, I set Distribution for the scheme of the target that I want archive and publish since that is the target configuration I want to archive.

Then go to the build settings, click on the desired target, click on the build settings tab, and then scroll down to the code signing. For the Distribution configuration in the code signing, I verify that the desired distribution provisioning profile is selected for the two entries under the Distribution configuration (Distribution and any iOS SDK).

 

After verifing that the code signing is accurate, from the target selection drop down list box in the toolbar in the top left corner of Xcode, select iOS device. If you do not do this step, then the Archive option is greyed out and cannot be selected.

From the Xcode menu, select Product -> Clean.

In the Xcode menu click on Product -> Archive.

The Organizer should then launch showing the newly archived app.

After archiving a properly code signed app, from within Organizer, you can then choose to validate your app. Validation checks to see if the app has the necessary things to submit it to the Apple App store as well as verifies that you have configured an App ID, provisioning profile, created the app in Itunes Connect, and that the state of the app in iTunes Connect is Waiting For Upload.

Validation is automatically done on an app when you choose Distribute in the Organizer and then choose Submit to the iOS App Store and click Next.

You will then need to select the app and the code signing again before uploading the app to Apple for review if you have more than one app that is in the Waiting For Upload state.

If you are distributing your app via ad hoc, then save the file and distribute the app package to the the users of the devices that you had setup for ad hoc distribution (note that you can have a maximum of 100 devices for ad hoc distribution).

All that is left now is to authenticate with your iTunesConnect user name and password and click next.

Your app will then upload to the Apple App Store and the status of your app in iTunes Connect will change to Upload Received and go through an automated validation. If it passes the automated validation, usually within 15 minutes, the status will change to Waiting For Review.

After about 5 business days your app will be either approved or rejected by the Apple app review folks. I have submitted apps over 100 times via this process given that I have 38 apps in the Apple App store and have updated each multiple times. Apple must have review teams at different locations around the world because sometimes I have had apps approved at unusual times, such as 11pm on a Saturday night. Apple works hard at getting these apps approved quickly. I have had some apps approved within 24 hours of uploading and the longest approval wait time was about 8 days.