Application Development Overview

Developing for the App Store
Contents
About the Application Development Process 5

At a Glance 5 Developing for Apples Platforms Is a Mix of Administrative and Coding Tasks 5 Apps Published on the App Store Must Be Approved by Apple 5 Apps Published on the App Store Must Be Cryptographically Signed 6 The Majority of Your Coding Time Is Spent in Xcode 6 Administrative Tasks are Performed with Several Resources 6 Many Behaviors of an App Are Defined by Data, Not Code 7 How to Use This Document 7
Building an App for the App Store 8

Prepare the Development Team 8 Configure the Project 8 Develop the App 9 Publish the App in the App Store 9
Preparing the Development Team 10

Enrolling in an Apple Developer Program 10 Adding Members to a Team 11 Understanding Membership Privilege Levels 11 Organizing the Team in iTunes Connect 13 Organizing the Development Team 14 Creating Your Teams Signing Certificates 17 An Example: Signing an iOS App During Development 17 Setting Up a Developer for Code Signing 20 To Learn More 21
Creating a Project 22
Configuring an Xcode Project for an App 22 Creating Provisioning Profiles for Your App 23 App Concepts 23 A Bundle ID Uniquely Identifies an App 24 App IDs Are Used to Match Apps to Services and Development Teams 25 Provisioning Profiles Authorize an App to Launch 26
2012-07-17 | 2012 Apple Inc. All Rights Reserved.
Contents
Distributing an App Requires a Distribution Profile 28 To Learn More 28
Developing an App 29
Designing an App 30 Use the Model-View-Controller Pattern 31 Use Data-Driven Designs 32 Writing Code 33 Treat Warnings as Errors 33 Use the Analyze Action in Xcode to Find Less Obvious Coding Errors 34 Implement Unit Tests and User Interface Tests 34 Polishing and Testing an App 35 Test on Various Devices 35 Use the Archive Action to Create Test Versions of an App 35 Use Instruments to Guide Your Efforts 35 Ensure That Your App Meets the Approval Guidelines 36 Creating Great Apps 36 Design User-Focused Apps 36 Develop a Security Model 36 Ensure Your App Runs Reliably 37 Tune Your Apps Performance 38 To Learn More 38 Best Practices in Coding and App Design 39
Publishing an App in the App Store 40

Configuring App Data in iTunes Connect 40 Submitting the App for Approval 41 Shipping an App 41 Responding to User Issues 42 To Learn More 42
Document Revision History 44 Glossary 45
Figures and Tables
Building an App for the App Store 8

Figure 1-1 Development process overview 8
Preparing the Development Team 10

Figure 2-1 Figure 2-2 Figure 2-3 Figure 2-4 Figure 2-5 Figure 2-6 Table 2-1 Table 2-2 Table 2-3 Table 2-4 Steps to create a development team 10 An individual is the team agent 15 A small development team 15 A large development team 16 Overview of the iOS development provisioning process 18 The process for approving a device and getting a signing certificate 20 Team roles 12 Privileges assigned to each membership level 12 iTunes Connect roles and responsibilities 13 Abbreviated list of iTunes Connect modules, including availability by role 14
Creating a Project 22
Figure 3-1 Figure 3-2 Figure 3-3 Figure 3-4 Figure 3-5 Figure 3-6 Starting a new project 22 Common uses for an apps bundle ID 24 Explicit app ID 25 Wildcard app IDs 26 Examples of wildcard matching 26 Overview of the development provisioning process 27
Developing an App 29
Figure 4-1 Figure 4-2 Figure 4-3 Figure 4-4 The development process 29 The development process is an iterative process 29 Distribution between development tasks varies over time 30 Model-View-Controller pattern 31
About the Application Development Process
There has never been a better time to create apps for iOS and OS X. Apple provides tools that make development easy and straightforward. This document presents a high-level view of the stages in developing an app, from creating a team to responding to feedback from users.
Develop
Test
Distribute
At a Glance
This document walks you through the process of developing apps for the App Store. By the time you finish reading this document, you should be ready to organize your development team and devise a plan to design, code, and publish an app on the App Store.
Developing for Apples Platforms Is a Mix of Administrative and Coding Tasks

Most of the time spent developing your app is spent on coding tasks, but throughout the development process, there are also a number of administrative tasks you must perform. This mix of tasks can be handled by a single developer, or the work can be divided between different people on a development team. Most administrative tasks appear at the start and the end of a development project. For example, when you develop your first app, one person must sign an agreement with Apple to become an Apple developer. This person, known as the team agent, bears the legal responsibility for the team, adds people to the team and defines each persons responsibilities and privileges. Chapters: Building an App for the App Store (page 8)
Apps Published on the App Store Must Be Approved by Apple

The App Store is a curated store and restricts what apps may be sold on the App Store. Apple takes these precautions to provide the best experience possible for our users. For example, apps that are sold on the App Store must not crash or exhibit other major bugs. A major part of the publishing process is to submit your app to Apple for approval.
About the Application Development Process At a Glance
Relevant Chapters: Publishing an App in the App Store (page 40)
Apps Published on the App Store Must Be Cryptographically Signed

Code signing is used to provide a layer of security to users, your development team, and Apple. Signing an app makes it resistant to malicious tampering; if an attacker modifies the app, it can no longer be executed because the code signing has been broken. Code signing also provides a clear chain of responsibility if malicious code is included in a signed app. Although both iOS and OS X require code signing to publish an app on the App Store, iOS takes this security a step further; no apps can execute on an iOS device, even during development, unless they are signed. When you organize a development team, the team agent (or a person that task is delegated to) decides which members of your team are permitted to sign your apps and creates the necessary code signing resources for those developers. Relevant Chapters: Preparing the Development Team (page 10), Creating a Project (page 22)
The Majority of Your Coding Time Is Spent in Xcode

Xcode integrates coding, debugging, and user interface design in a single development environment. You use Xcode throughout the development process, even using it when you are ready to submit an app for approval. When you install Xcode, other apps are installed with Xcode that you can use to improve the quality of your apps. For example, the Instruments application provides many tools to record and analyze data about how an app acts while running. Using the data, you can formulate plans to ensure that your apps run correctly and efficiently. Relevant Chapters: Creating a Project (page 22), Developing an App (page 29)
Administrative Tasks are Performed with Several Resources

When you manage a team, you use various resources to perform tasks. Here are the most frequently used resources:
The Member Center website is primarily used by the team agent to invite members to join the development team and to configure their privilege levels. The iOS Provisioning Portal (or for OS X development, the Developer Certificate Utility app) is used to create the code signing resources for your team. A team admin (either the team agent or a member of the team this task has been delegated to) uses these tools to provide the necessary code signing resources to members of your team.
About the Application Development Process How to Use This Document
The iTunes Connect website is used to manage information related to the business side of your app development, including sales and financial information, information displayed in the App Store for your app, and information stored on Apples servers for your apps. As with the Member Center, the team agent decides how much access each person on your team is permitted on iTunes Connect.
Relevant Chapters: Preparing the Development Team (page 10), Creating a Project (page 22), Publishing an App in the App Store (page 40)
Many Behaviors of an App Are Defined by Data, Not Code

In addition to the code you write, data you provide is used to define how the store displays your app as well as how your app executes. The data can even affect what the operating system displays about your app when it isnt running. Some data is contained in files stored alongside an executable; this combination of data and files is referred to as an application bundle. Other data is stored on Apple serversfor example, information displayed for your app on the App Store is primarily stored on iTunes Connect. Regardless of where the data is stored,keep in mind that an app is more than a simple executable; it exists in an ecosystem of code, data, and services. Relevant Chapters: Creating a Project (page 22), Developing an App (page 29), Publishing an App in the App Store (page 40)
How to Use This Document

Regardless of the role you play on a development team, you should read this document to get a better understanding of steps the team must follow to develop an app for the App Store. If you are a programmer, some concepts described in this document will make more sense to you if you finish one of the following app tutorials before reading this document:
iOS: Start Developing iOS Apps Today OS X: Start Developing Mac Apps Today
Building an App for the App Store
Here are the steps to create and ship an app for the App Store. Although these steps are presented in a specific, logical order, occasionally the needs of your app or your development team require you to perform these steps in a different order or even backtrack to a step you have already performed. For example, any time you add someone to your team, you have to go back and perform some administration tasks. Figure 1-1 shows a high-level overview of the development process; each of these steps is primarily an administrative step or a coding step. Administrative steps are usually handled by the team agent or someone the team agent has delegated some authority to. Coding tasks are primarily handled by programmers on the team.
Figure 1-1 Development process overview
Administrative Prepare the development team Coding Administrative Publish the app in the App Store
Create a project
Develop the app
The remainder of this chapter explains each of these steps. Later chapters go into more detail about the steps and the kinds of tasks that must be performed to complete them.
Prepare the Development Team

One person signs up as a team agent and in the process creates a new development team. The team agent can invite other people to join the team and set their access privileges. Finally, the team sets up code signing certificates and other resources necessary for developers on the team to sign apps.
Configure the Project

The next step is to create a new Xcode project for the app. You choose an Xcode template that most closely corresponds to the kind of app you want to make and customize the initial settings for the app. You also create other items required to sign and publish your app.
Building an App for the App Store Develop the App
Depending on the design of your app and the services you plan to use in it, you may find yourself performing other kinds of app configuration in this step. Some Apple technologies require a combination of code you write and data you configure to operate properly. For example, Apple Push Notification Service requires you to create special certificates used to authenticate your server to the push notification service. If you know up front that you plan to use push notification in your app, you may also create these push notification certificates during this step.
Develop the App

This step is what most people think of when they talk about developing an app: Designing user interfaces and functionality, implementing those ideas in code, and testing the resulting app to ensure it works correctly. While a lot of this work is programming, this step also includes other important tasks, such as creating data assets used by the app. These assets, including but not limited to icons, sound files, and artwork, are used directly by the app or by the operating system on the apps behalf. Many assets need to be localized into other languages or locales; an important part of designing your app is planning for the assets you need to create and knowing which assets should be localized. You continue to polish and refine your app until it is ready to ship.
Publish the App in the App Store

Publishing an app on the App Store requires a few administrative tasks. Your team provides the information displayed for the app by the App Store. You also submit the app to Apple for approval. Once the app is approved, you set the date the app should appear for sale in the App Store. Then, you use Apples tools to monitor the sales of the app, customer reviews, and crash reports. These data can help you prepare bug fixes and help you decide on what improvements to make in a major revision to the app. When you have bug fix or a major revision ready to ship, you send it for approval and set a publication date, just as you did for the initial release.
Preparing the Development Team
Most people think of a development team as a group of programmers, designers, and artists who work together to develop an app. That explanation is also true when you develop for iOS or OS X, but it isnt complete. A development team takes on the additional meaning of a group created and managed on the Apple Developer website. Some additional tasks during the development process are performed using this development team youve created. If you create a team with yourself as the only member, you take on all of these tasks. If you are part of a larger team, the work and the responsibilities may be divided between the group. Each person on the development team has a unique Apple ID, an account used by the developer programs to authenticate that person. Further, access privileges can be configured separately for each person. This flexibility allows your team to restrict critical tasks, such as publishing the app on the App Store, to a small subset of its participants. This chapter starts by describing the various roles that members of a team may fill. It then provides guidance about how you may want to go about organizing the team. Finally, it describes work the team must do to allow people of the team to sign apps. Figure 2-1 shows all of the required steps.
Figure 2-1 Steps to create a development team
Administrative Enroll in an Apple developer program Organize the team in iTunes Connect Create the teams signing certificates
Add members to the team
Enrolling in an Apple Developer Program

To start, one person must enroll in either the iOS or OS X developer program; this person becomes the team agent for the team. The team agent may enroll in both programs if your team intends to develop apps for both operating systems. During this step, the team agent signs the legal agreements required to become an Apple developer and prepares the financial paperwork so that the team can be paid for purchases from the App Store.
10
Preparing the Development Team Adding Members to a Team
The team agent is special; he or she has unrestricted access to the team and is legally responsible for the team. The team agent also performs most of the tasks to organize the team. If desired, after others have joined the team, the team agent can delegate some of this authority to other members of the team, allowing those others to perform these tasks instead. Important: Because the team agent is the person with legal responsibility for the team, the team may not demote the team agent using the tools on the website, nor can the team agents privileges be restricted. To change the person acting as the team agent, you must contact Apple directly. The team agent might need to sign updated or new licensing agreements, particularly when the team wants to incorporate specific technologies into an app. For example, an app that uses the iAd service requires your team agent to sign a separate agreement.
Adding Members to a Team

After the team agent has joined a developer program, he or she adds other people to the team and sets their privileges. If you are the team agent and the sole developer on your team, no additional configuration is needed, because the team agent always has access to all account features. However, you should continue to read this section to understand the kinds of tasks you may need to perform throughout the rest of the development process. To add a new person to the team, the team agent sends an invitation to the person; part of sending an invitation includes setting that persons privileges on the team. When he or she accepts the invitation, that person is automatically added to the team.
Understanding Membership Privilege Levels

A persons membership level on the team defines the level of access he or she has to the Apple developer webpages and the team information stored there. This privilege level extends to the kinds of tasks that developer is allowed to perform on behalf of the team. For example, only certain members of the team are allowed to publish apps on the App Store. By giving you control over these task privileges, Apple makes it easier for you to maintain good security practices for the team. If the team has joined multiple developer programs, when you configure a persons privileges, you set a separate privilege level for each program. You can also choose to not give someone access to a program. Table 2-1 lists the roles a team participant can play and provides a basic description of each. Each level of access includes all the capabilities of the levels below it.
11
Preparing the Development Team Adding Members to a Team
Table 2-1 Role
Team roles Description
Team agent
A team agent is legally responsible for the team and acts as the primary contact with Apple. The team agent can change the access level of any other member of the team. A team admin can set the privilege levels of other participants, although a team admin cannot demote the team agent. Team admins manage all assets used to sign your apps, either during development or when your team is ready to distribute an app. Team admins are the only people on a team that can sign apps for distribution on nondevelopment devices. Team admins also approve signing certificate requests made by team members. A team member gains access to prerelease content delivered by Apple on that programs portal. A team member can also sign apps during development, and but only after he or she makes a request for a development signing certificate and has that request approved by a team admin.
Team admin
Team member
Table 2-2 drills deeper into this list of privileges granted to members of your team. Although this document hasnt explained all these privileges, most will be clear to you by the time you finish reading it.
Table 2-2 Privilege Privileges assigned to each membership level Team agent Team admin Team member
Legal responsibility for the team Primary contact with Apple Invite team admins and team members Approve a request for a development signing certificate Add devices for development and user testing Create app IDs Request a distribution signing certificate from Apple Create development and distribution provisioning profiles
12
Preparing the Development Team Organizing the Team in iTunes Connect
Privilege
Team agent
Team admin
Team member
Enable app IDs to use Apple Push Notification or In-App Purchase Create SSL certificates for the Apple Push Notification Service Request a development signing certificate Download development provisioning profiles View prerelease website content
Organizing the Team in iTunes Connect

The privileges set in the previous section primarily pertain to the development process: They define who is allowed to sign apps, who is allowed to create signing certificates, and so on. However, the team agent also manages access privileges to the iTunes Connect website. For example, changing the price of an app is a task you likely want to limit to a small number of people on your team. Access to the iTunes Connect website is configured separately and is designed to be more fine-grained than the access you set in Member Center. On iTunes Connect, each person on the team can be assigned one or more roles; each role has different privileges. Table 2-3 describes the roles at a high level.
Table 2-3 Role iTunes Connect roles and responsibilities Responsibilities
Legal
The legal role is automatically assigned to the team agent, and only the team agent is permitted to have this access. The legal role allows the team agent to sign legal contracts and other agreements. The admin role grants access to all tasks in iTunes Connect except for those assigned to the legal role. A team agent is always assigned the admin role, and this access cannot be revoked without changing which person on the team acts as the team agent. An admin can assign iTunes Connect roles to other people on the team. The finance role grants access to financial reports and sales information. The finance role also authorizes the person to view contract, tax, and banking information. The sales role grants access only to sales data.
Admin
Finance
Sales
13
Preparing the Development Team Organizing the Development Team
Role
Responsibilities
Technical
The technical role grants the ability to edit the app information stored in iTunes Connect and to create test accounts needed to test In-App Purchase support in an app.
Table 2-4 lists the most common modules you need to access in iTunes Connect, along with the roles that are allowed to access each module. The legal role is not shown, because only the team agent has those rights. All participants have the ability to edit their own personal details stored in their accounts in iTunes Connect.
Table 2-4 Abbreviated list of iTunes Connect modules, including availability by role Admin Finance Sales Technical
Responsibility
Manage Users Manage Your Applications Manage Test Users Sales and Trends Contracts, Tax, and Banking Payments and Financial Reports
Organizing the Development Team

Now that you understand the roles people can assume in Member Center and iTunes Connect, you should consider how you want to organize the team. Organizing the team requires more than setting privileges described above. The size of the team affects how you organize it and its assets.
14
The smallest team is a single personyou. You act as the team agent and have full privileges to perform any task. The disadvantage of a one-person team is that you have to do all the work. You need to set up the assets needed to sign and publish an app, configure all the information in iTunes Connect, develop an app, and market it.
Figure 2-2 An individual is the team agent
Agent
Admin
Members
A more common configuration is a small developer team. On a small team, the team agent is also a programmer, but defers some of the administration overhead to another person on the team. The team agent handles all of the financial and sales operations for the team, while the team admin ensures that the developers on the team have what they need to get the job done.
Figure 2-3 A small development team
Source code server Agent
Admin
Members
15
If your team is large, you can divide the tasks further. Some people on the team might not be programmers, including the team admin. The sales and financial roles might be filled by people with a business background. You might even have in-house testers who are not also programmers. The task of creating and shipping apps could be delegated to one or more dedicated team admins. You might even partition the work further and divide the team between iOS and OS X development.
Figure 2-4 A large development team
Build bot Agent
Admins
Members
Source code server
Finance
Sales
Testers
As the team grows, the need for coordination between the different people on the team increases. In particular, the cost of development errors increases when you have more programmers on the team. For example, if you are the sole member of the team, you can store all your work on a single computer and do all of the work there. Xcode even allows you to create a local source code repository to store your code. But what happens when the team grows in size? When the team grows to a moderate size, you need more infrastructure. You want a separate computer to act as a remote source code repository; members of the team pull down the code from the remote repository to their computers, make changes, and send those changes back to the server. But when multiple developers are syncing code, the chance of an error being checked into the code increases. To minimize problems, you usually want multiple branches of development, including stable branches that hold the code you use to build your
16
Preparing the Development Team Creating Your Teams Signing Certificates
shipping app and experimental or developmental branches used for new development. These strategies require a deeper understanding of the underlying source code repository and require you to define specific policies that describe how code gets integrated between the different branches you maintain. If your team grows very large, checking erroneous code into developmental branches could impair your teams productivity. By the time you discover an error, it might already have been synced to other peoples computers. After you correct the error, propagating the fixes to everyone on the team still takes time. The frequency of such incidents and the time lost for each incident increase as the size of the team increases; these losses, when aggregated, cripple your teams effectiveness. To avoid this lost productivity, you should add additional infrastructure for code management. For example, you might adopt a process of continuous integration by creating a dedicated build machine (known as a build bot) that automatically checks out each change and rebuilds your app. By building new changes as they arrive, you discover errors earlier; you might even configure the server to back out such changes before others on the team pull down the offending code. If your project includes unit tests or automated user tests, the build computer can also run those tests to verify that your source code still passes the tests. This process, known as smoke testing , increases the teams confidence that code stored in the development branches builds and works properly. As the team grows larger, you want to automate tasks that are repeatable, predictable, and costly to perform by hand. By automating common tasks, you reduce the burden on the team and allow it to focus on designing and implementing code.
Creating Your Teams Signing Certificates

Apps distributed on the App Store must be cryptographically signed. You may also need to sign the app during development.
On OS X, an app must be signed during development if it uses iCloud or application sandboxing. On iOS, all apps must be signed during development.
Regardless of which platform you are developing for, everyone on the team should understand the code signing process. This section describes the assets that are needed to sign an app and authorize it to run on a device, and then explains how people on the team acquire the assets they need to sign apps. Some of these assets should be created now as you organize your team; the rest are created each time you start a new project.
An Example: Signing an iOS App During Development

Figure 2-5 shows everything that is needed to build and sign an iOS app during development. Signing apps during OS X development or signing to distribute an app on either platform follows similar procedures. For now, focus on this example. While you are developing an iOS app, it can only be installed on iOS devices
17
specifically marked for development. To run an app on such a development device, you install a signed version of the app and a development provisioning profile that authorizes the signed app to be launched. Without a profile that authorizes it to launch, iOS prevents the app from launching.
Figure 2-5 Overview of the iOS development provisioning process
Team member
Xcode project Private key Development signing certificate Public key Intermediate signing certificates
Team admin
List of authorized signing certificates App ID List of authorized device IDs
Development Provisioning Profile List of certificates Build and sign App ID List of device IDs
Signed application
Development device
Creating development provisioning profiles is described in detail in Creating a Project (page 22); for now, understand that a development provisioning profile is a signed file whose contents define the scope of the profile:
The development profile authorizes a specific set of apps to run. The development profile authorizes a specific list of devices to run those apps. The development profile authorizes a specific list of development certificates to sign those apps.
18
In addition to being installed on the development device, the profile must be installed on your development computer also. The profile authorizes the copy of Xcode to sign the app. Xcode only signs an app and installs it on the device if the profile authorizes the signing certificate and the app being signed. Logically, this makes sense; if a profile that authorizes the app to launch is not available, such an signed app would serve no purpose. Next, take a close look at the left side of Figure 2-5. To sign code during development, you need the following items installed in the keychain on your development system:
A private key. A development signing certificate (authorized by a team admin). This signing certificate includes the public key associated with the private key. An intermediate signing certificate (provided by Apple). This certificate acts as an intermediary between your development signing certificate and the signing authority.
The combination of a signing certificate and the corresponding private key is called a code signing identity. When you build an iOS app, Xcode compiles it, signs it using your code signing identify, and installs it on the device. If a provisioning profile compatible with the signed app is also installed on the device, you can launch and debug the app.
19
Setting Up a Developer for Code Signing

Figure 2-6 shows the process for setting up a new developer on the team. The full details of this process are spelled out in documents listed later in this chapter; see To Learn More (page 21). For now, you only need to understand this process at a high level. Team members make requests; team admins authorize or deny these requests. There are two separate pieces that need to be authorized: adding a development device to the teams devices and creating the code signing identity used to sign apps during development.
Figure 2-6 The process for approving a device and getting a signing certificate
Team member Sends the device ID to a team admin Creates a public key / private key pair Sends a request for a signing certificate Approves the signing certificate request Installs both the signing certificate and the intermediate certificate Adds the device ID to the list of devices Team admin
Time
To add a device to the team, you send the unique device ID (UDID) for the device to a team admin; this process happens outside of any tools provided by Apple. For example, you might send an email to the team admin with the devices device ID. The team admin adds the device to the teams devices. Typically, the team admin also adds this device to any development provisioning profiles associated with the team, although that is not strictly required. For example, if your team wants to limit an app to specific devices, then you might choose to add the device only to a subset of the teams profiles. To get a signing certificate, a team member uses Xcode to request a signing certificate. Xcode automatically creates a new public and private key and requests that a new development signing certificate be created for the team member. After a team admin receives and approves the certificate request, the team member can use Xcode to automatically install the required pieces into the keychain. Although setup is described here as a single process, you do not need to perform both steps for every member of your team. For example, you might want internal testers to be associated with the development team on the Apple Developer website but not allow those testers to build and sign your app. In this case, the team
20
Preparing the Development Team To Learn More
admin might include a testers device in the teams devices but not allow the tester to create a code signing identity. Similarly, an external testers device must be included in the teams device list in order for it to be authorized to run an app. While the above discussion was about development signing certificates, when you organize your team, the team should also request a distribution signing certificate. A distribution signing certificate is required if you intend to distribute apps to nondevelopment devices. Unlike development signing certificates, where each team member has a separate code signing identity, a team has a only one code signing identity used to sign apps for distribution. The procedure for creating a distribution certificate is similar to the workflow described above, but the request for a distribution signing certificate is made by a team admin using a new public/private key pair and Apple approves the request. After the certificate is approved by Apple, only a team admin can download the resulting certificate. Important: All developers on the team should keep a secure backup of their private key. If the key is lost, that team member can no longer sign code without creating a new identity. Worse, if the key is stolen, another person may be able to impersonate that developer. Protecting the private key associated with the teams distribution signing certificate is absolutely critical ; in the wrong hands, someone might be able to impersonate your team, and upload malicious software for app approval. Private keys are stored only in the keychain and thus cannot be retrieved if lost. If a developer on your team needs to set up another development computer, in order to sign code, he or she must also copy the private key over to the new computer.
To Learn More
If you are on an iOS team, read the following documents to learn more about creating a team and setting up its signing certificates:
If you are a team admin, read iOS Team Admin Guide . If you are a team member, read Tools Workflow Guide for iOS . Read iTunes Connect Development Guide for a comprehensive description of iTunes Connect and the tasks you perform there.
If you are on an OS X team, read the following documents to learn more about creating a team and setting up its signing certificates:
Regardless of whether you are a team member or a team admin, read Tools Workflow Guide for Mac . Read iTunes Connect Development Guide for a comprehensive look at iTunes Connect and the tasks you perform there.
21
Creating a Project
When you are building apps to learn more about app development or to experiment with a concept, you might not follow the formal process listed here. When your app is destined for the App Store, you should do more work up front. Figure 3-1 shows the steps you should perform when starting work on a new app. This chapter explains the steps you should follow to organize your project and other related items you need in order to distribute your app. It then explains many of the important concepts related to those steps.
Figure 3-1 Starting a new project
Coding Administrative Create provisioning profiles
Configure an Xcode project for the app
Configuring an Xcode Project for an App

When you create a new Xcode project, you are presented with settings to configure the new project; you can find more information about these settings in Tools Workflow Guide for iOS and Tools Workflow Guide for Mac . You should carefully consider the template you use to create an app and the settings used to configure the project; starting with the right template helps speed the development process. For example, if you were planning to write an iOS game using the OpenGL ES graphics framework, the OpenGL ES Application template is an ideal starting point, because it provides a lot of initialization code required by all OpenGL ES apps. One of the settings you provide when you create a new project is the bundle ID for your app. When you set the bundle ID, it is automatically inserted into your projects information property list file.
22
Creating a Project Creating Provisioning Profiles for Your App
Note: When you create a new project, Xcode gives you the option to automatically create a local source code repository. You almost always want to select this option, even for test projects. Using source code control is essential to good development practices. It ensures that you have a working history of the work youve completed on your app, allowing you to make changes to your code knowing you can revert changes that did not work out as intended. You can even use Xcode to easily compare the working copy of your source code with the code stored in your source code repository.
Creating Provisioning Profiles for Your App

If you intend to ship your app on the App Store, a team admin should perform these steps after your project is created:
1. 2. 3.
Create an explicit app ID whose bundle ID search string exactly matches the new apps bundle ID. Use the new app ID to create a development provisioning profile. Use the new app ID to create one or more distribution provisioning profiles.
Although an explicit app ID is not strictly required for all projects, having one, and the related provisioning profiles, gives you finer control over who can build and run each app you create. An explicit app ID is also necessary for many Apple services; creating it early means you are always ready to implement those services in the app. Similarly, a distribution provisioning profile isnt necessary until you are ready to distribute your app, but creating those profiles at the start of the project makes it easier for you to verify that your signing and provisioning is set up correctly. Creating an ad hoc distribution profile at the start of your project also allows you to build a release version of the app at any time and send it to external testers using nondevelopment devices.
App Concepts
When you create a project, you use a bundle ID to identify a specific app, and an app ID to match that bundle ID. The app ID is used as part of a provisioning profile that authorizes an app to launch. The next few sections describe these three concepts in detail.
23
Creating a Project App Concepts
A Bundle ID Uniquely Identifies an App

A bundle ID is a string used to precisely identify a single app. Bundle IDs are not used just during the development process; when your app is installed on a device, it is also used by the operating system. For example, the preferences system uses this string to identify the app for which a given preference applies. In contrast, Launch Services uses the bundle ID to locate an app capable of opening a particular file, using the first app it finds with the given identifier. And, in iOS, the bundle ID is used in validating the apps signature. The bundle ID string must be a uniform type identifier (UTI) that contains only alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.) characters. The string should be in reverse-DNS format. For example, if your companys domain is Ajax.com and you create an app named Hello, you could assign the string com.Ajax.Hello as your apps bundle ID. During the development process, you use an apps bundle ID in many different places to identify the app. Figure 3-2 shows the most common places where an apps bundle ID is used during the development process.
Figure 3-2 Common uses for an apps bundle ID
Xcode project
iTunes Connect Bundle ID App ID
iCloud container ID
The bundle ID itself is stored in the information property list file (Info.plist) inside your project. This file is later copied into your apps bundle when you build the project. When you are ready to publish an app, you use the bundle ID to identify the app in iTunes Connect. The App Store submission process correlates the bundle ID from the app you submit with the data you provide in iTunes Connect. See Configuring App Data in iTunes Connect (page 40). When developing your app, you need a development provisioning profile with an app ID that is compatible with the apps bundle ID. When you implement iCloud support in your app, the container IDs you specify are based on the bundle IDs of one or more apps.
24
App IDs Are Used to Match Apps to Services and Development Teams
App IDs are strings and share some characteristics with bundle IDs. But app IDs differ in two important ways. First, app IDs are not required to identify a specific appan app ID can instead identify a collection of apps. Second, an app ID contains additional information that allows it to be associated with a specific development team. Although the convention for bundle IDs starts each with a company identifier in reverse DNS format, that convention is not strictly enforced, and it cannot be used to identify your development team. App IDs are primarily used when creating development and distribution provisioning profiles, both described later in this chapter. An app ID is a string containing two parts, a team ID and a bundle ID search string, with a period (.) separating the two parts. Each part of an app ID has different and important uses for your app. The team ID is a unique 10-character string generated by Apple. The team ID is what associates an app ID with a specific team. Apps that share the same team ID can also share keychain data, such as user names and passwords. Two kinds of app IDs are supported: wildcard app IDs and explicit app IDs . The bundle ID search string determines the type of an app ID.
Explicit App IDs Match a Single App

An explicit app ID uses a search string that exactly matches the bundle ID of an app you are building. Because the exact bundle ID is specified, the app ID matches only that app.
Figure 3-3 Explicit app ID
Team ID (generated by Apple)
A1B2C3D4E5comdomainnameapplicationname
Bundle ID search string (determined by Developer)
Important: In order to incorporate Apple Push Notification Service (APNS), In-App Purchase, or Game Center features into your app, you must create an explicit app ID for your app.
Wildcard App IDs Match Multiple Apps

A wildcard app ID allows you to use an app ID to match multiple apps; wildcard app IDs are useful when you first start developing new apps because you dont need to create a separate app ID for each app. However, wildcard app IDs cant be used to provision an app that uses APNS, In-App Purchase, or Game Center.
25
A wildcard app ID omits some or all of the bundle ID in the search string and replaces that portion with an asterisk character (*). The asterisk must always appear as the last character in the search string.
Figure 3-4 Wildcard app IDs
Team ID (generated by Apple) Team ID (generated by Apple) or,
A1B2C3D4E5 *
A1B2C3D4E5comdomainname *
When you use a wildcard app ID, characters preceding the asterisk (if any) must match the characters in the bundle ID, exactly as they would for an explicit app ID. The asterisk matches all remaining characters in the bundle ID. Further, the asterisk must match at least one character in the bundle ID. Figure 3-5 shows an example search string and shows that it matches some bundle IDs but not others.
Figure 3-5 Examples of wildcard matching
comdomain *
(bundle id search string)
comdomaintext
comdomainicon comdomain
* matches text. * matches icon.

The d in the pattern fails to find a match. The in the pattern fails to find a match. The * in the pattern fails to match a character.
comotherdomaindatabase
comdomain
If an app ID uses an asterisk (*) as the bundle ID, then the search string matches any bundle ID.
Provisioning Profiles Authorize an App to Launch

In the chapter Setting Up a Developer for Code Signing (page 20), you learned how signing certificates are created and used to sign app. Now, you need to learn about the other half of the process, the provisioning profiles used to authorize signing and execution of an app. There are two kinds of provisioning profiles:
A development profile, used during development, can be used to authorize apps only on devices configured for development. A distribution profile is used to distribute apps. There are multiple kinds of distribution profiles, each associated with a specific method of distribution.
26
Figure 3-6 shows the development provisioning process for iOS development again.
Figure 3-6 Overview of the development provisioning process
Team member
Xcode project Private key Development signing certificate Public key Intermediate signing certificates
Team admin
List of authorized signing certificates App ID List of authorized device IDs
Development Provisioning Profile List of certificates Build and sign App ID List of device IDs
Signed application
Development device
When you add devices and signing certificates to a development team, Xcode automatically creates a profile named iOS Team Provisioning Profile . This profile is automatically updated when new signing certificates or devices are added to the team. This profile has three major characteristics:
It includes all code signing certificates associated with the team. It includes all devices associated with the team. The app ID in the profile uses an asterisk as the bundle ID.
In other words, the iOS Team Provisioning Profile allows any app to be signed by any team member with a signing certificate and installed on any team device. Because the iOS Team Provisioning Profile is automatically updated, this profile is very helpful when programmers on your team want to install sample code or simple
27
Creating a Project To Learn More
test apps on development devices. However, when you are developing an app for the App Store, you may want to create a development provisioning profile instead. When you create your own profile, you can limit any of the three areas to provide additional security:
You can use an app ID that allows a subset of the teams apps to be launched; with an explicit app ID, you can limit the profile to a single app. You can restrict the developers allowed to sign app authorized by the profile. You can restrict the devices that apps authorized by the profile may be installed onto.
Distributing an App Requires a Distribution Profile

When you are ready to distribute an iOS or Mac app, you not only need the distribution signing certificate created when you organized your team, you also need a distribution profile that authorizes the app to run. If you are developing an iOS app, signing the app and distributing it with the appropriate profile is the only way to install the app on a device not specially configured for development. The exact contents of a distribution profile differ from the contents of a development profile, and each kind of distribution profile may have slightly different contents. A common requirement limits code signing to the teams distribution signing certificate. That said, a distribution profile for distributing an app on the App Store doesnt restrict the app to a limited set of devices.
To Learn More
If you are on an iOS team, to learn more about the different kinds of distribution profiles and to learn how to configure a new project, read the following documents:
If you are a team admin, read iOS Team Administration Guide . If you are a team member, read Tools Workflow Guide for iOS .
If you are on an OS X team, learn more about the different kinds of distribution profiles how to configure a new project by reading Tools Workflow Guide for Mac .
28
Developing an App
Figure 4-1 shows a typical organization of the development process. You design what you want your app to do and how it should work, implement those ideas in code, and then test the code youve written.
Figure 4-1 The development process
Coding
Design the app
Write code for the app
Polish and test the app
The figure above gives you an idea of the process, but it doesnt express the reality of it. In practice, it looks more like the process shown in Figure 4-1.
Figure 4-2 The development process is an iterative process
Design the app
Write code for the app Polish and test the app
It is up to you to decide how much time you plan to put into each phase as you iterate through the development of your app. For example, you might choose to implement a small number of features on each pass, as is typical in Agile development, or you might choose to write a design specification that describes how everything should work in your app and implement it all at once, or you might choose something in between. Regardless of which approach you use, polishing your app and iterating over elements of your design is essential to delivering a good experience to the user. You want to make sure your app provides an interface that users can easily understand; that task is difficult to accomplish without putting your app in front of users and observing how they interact with it.
29
Developing an App Designing an App
As you iterate through the development process, notice how your time is divided among the three phases varies. For example, at the beginning of the project, you have an idea, but no code to write or test, so more of your time is spent on design decisions. As you get ready to ship your app, your designs are mostly complete, you are changing the code only where necessary to fix problems, and you are spending the majority of your time testing to verify that your app works correctly and that users love it.
Figure 4-3 Distribution between development tasks varies over time
Design
Code
Test
Design
Code
Test
Design
Code
Test
Time spent in project
When you first start working on an app, start by reading the specific guides for the operating system you intend to target. These guides describe the technologies available to you, explain the architecture of apps on that operating system, and guide you on how your app should look and act to match the expectations of users. The rest of this chapter gives you a high-level overview of key development concepts to consider during each of the three steps in the iterative process.
Designing an App
When you start a new app, keep your design flexible. This suggestion is particularly true for a first app, when you are still learning the details of what makes a good app. Alternatively, assume your first project is not something you intend to ship but is used instead to learn more about the technologies you need to understand. By designing a flexible architecture, you are better prepared to respond to user feedback during your testing processand even after you ship, too. The following sections describe a couple of techniques that may help you with your initial design.
30
Use the Model-View-Controller Pattern

The Model-View-Controller pattern is one of many patterns in common use in Cocoa and Cocoa Touch, and it is essential to designing apps on iOS and OS X. When you use the Model-View-Controller pattern, you divide the concerns of your app into three major areas; these areas are typically represented in your app by different classes.
Model: What kind of data does your app store? How does it store it? Where is the data stored? View: What does your user interface look like? How is it composed? How does it animate? Controller: What tasks can a user perform? What things happen as the user interacts with your apps user interface? What tasks are necessary for your models and views to interact with each other?
By separating these concerns, you can revise one portion of your app without requiring significant changes in the rest of the app. This concept is important if you intend to redesign your user interface; ideally, you should be able to replace the user interface of your app without changing the model code. Being able to replace the user interface not only makes it easy to adjust the design of your user interface based on user feedback, it also makes it easy to extend your app to provide new user interfaces or share model classes between multiple apps. Figure 4-4 shows a single common data model applied across iOS and Mac apps.
Figure 4-4 Model-View-Controller pattern
Model
Controller
Controller
Controller
Controller
View
View
View
View
31
In the figure, the iOS app supports both the iPad user-interface idiom and the iPhone user-interface idiom and the Mac app supports both a windowed and full-screen interface. Using a common set of classes to represent your data model is ideal for an app suite designed to support iCloud; the apps store data in iCloud using a single file format, but each app uses a separate set of presentation objects. Thus, each app can be tailored to present an ideal interface for that kind of device.
Use Data-Driven Designs

Do not hard code all of the behavior into your apps source code. Instead, divide the work of your app between code and data. At runtime, the actual behavior of your app should be determined by the data. This pattern is used repeatedly through Cocoa and Cocoa touch. Here are a few examples:
Localization: Localization often includes storing localized text into strings files; these files are then loaded at runtime. This design allows the language of the user interface to be easily changed; when the app is relaunched after changing a localization setting, it automatically appears in the new language. Implementing a new interface in a different language may even be possible without changing the source code of your app. Nib file: A special file type, known as a nib file , stores objects as data. The data inside each nib file defines a custom collection of Objective-C objects, including the class and internal state of each object; this state includes references to other objects, connecting all of the objects into an object graph . When you develop an app, you create nib files and store them in your project; when you build the app, Xcode copies the files into the app bundle. When your app is running and needs new copies of the objects stored in the nib file, it instantiates the nib file. The operating system extracts the data stored in the nib file, re-creates the objects, and connects the resulting object graph to other objects in your app, just as if you had created and configured those objects programmatically. Nib files are used most often to store user interface objects and related objects such as controllers. Xcode allows you to create or modify nib files using graphical tools. Because the user interface elements are stored as data, you can often create or modify parts of your user interface without changing your apps source code. Although a programmer often defines the initial design of a nib files contents to connect the nib file to the underlying app code, separating the nib file as data makes it easier for nonprogrammers with specialized interface design skills to polish your apps user interface. Nib files can even be used to localize your app by loading different nib files at runtime based on the users preferred language or locale.
Storyboards: In iOS 5, storyboards replace nib files as the preferred way to design an user interface in Cocoa Touch apps. Storyboards share many of the same benefits of nib filesthey can be created using custom tools and stored in the project; the resulting storyboards are copied into the built app and loaded by the app at runtime. A storyboard differs from a nib file by allowing a single storyboard to hold multiple screens of content as well as transitions between those screens that are triggered when the app is running. The entire collection of screens and transitions is created and modified as a single entity, allowing you to better visualize how the user interface is organized. Xcode performs the necessary work to allow portions
32
Developing an App Writing Code
of the storyboard file to be instantiated efficiently, just as if you had created your design in multiple nib files. The details of how a storyboard does these things are not critical here; the important concept to understand is that storyboards are created and loaded as data. Adopting data-driven programming techniques in your own class designs can pay dividends in other areas as well. For example, a game might use data files to define the characteristics of elements in the gameplay. Cocoa and Cocoa Touch provide archiving classes that can store this data in a human-readable format, allowing your designers to open these files and tweak the design of the game without recompiling the code. And, although storing this data in files in your app bundle is the easiest way to implement this kind of design, you can even move these data files to a network server and allow your app to reload this data live. During development, the ability to reload game data without quitting your app can speed this iterative process even more. So, whether you load your files once at launch or allow the files to be reloaded, being able to change your apps behavior without recompiling code allows you work faster polishing your apps user interface and behavior.
Writing Code
When coding your app, start by reading the relevant programming guide for the technology you plan to use, if one is available. These guides often provide specific guidance on how classes in a particular framework are intended to be used together. Although you can try to learn how a framework works by reading the header files or the references, programming guides are designed to guide you through the design of the framework and how to structure your app to use that technology. Objective-C is a flexible language. That flexibility, and its underlying C architecture, make it easy to write apps that crash or run incorrectly. Ideally, you never want erroneous code to live in your project for very long, and you definitely dont want erroneous code to be checked into your source code repository. To avoid that, consider the practices described in the following sections.
Treat Warnings as Errors

Often, warnings indicate code that may not work properly at runtime. Even when a warning does not indicate a fatal error, its presence in your project may obscure more critical warnings that do represent errors. Be aggressive; set up your Xcode project to treat warnings as errors, and fix those errors just as you would any other compiler error.
33
Developing an App Writing Code
Use the Analyze Action in Xcode to Find Less Obvious Coding Errors
The Objective-C compiler has a built-in code analyzer that detects many common coding errors. It not only understands C programming errors, but it also has been programmed to enforce many Cocoa and Cocoa Touch coding conventions. Thus, if your app has subtle logic errors or is failing to conform to the coding conventions, it can provide an early indicator of a problem and explain exactly where your logic went awry. Always check your code with the Analyze command before committing it to the repository.
Implement Unit Tests and User Interface Tests

Unit tests are additional code you write to test your app. Because you understand the logic of how your classes are intended to be used, you can write targeted tests to verify that this behavior works correctly. A typical unit test instantiates objects from your apps classes, configures them, and then calls one or more methods on an object to perform actual work. Finally, the unit test executes one or more test assertions to verify that the results match what the test expected. Xcode has built-in support for unit testing; when you create your project, you can automatically have Xcode include a target that builds and runs unit tests. All you need to do is fill in the tests. By consistently and regularly using unit tests, you decrease the chance of a breaking change being introduced into your source code for any length of time. When you find a bug that your unit tests didnt detect, that bug is often an indication of another unit test you need to write. In addition to helping you verify that your classes work correctly, unit tests often improve the design of your classes. To test an object in isolation, the object must be able to be instantiated without having large numbers of dependencies on other objects or classes. You may even need to be able to override some of the behaviors of the instantiated test object so that it calls your test code, rather than calling some other subsystem of your app. This flexibility, when incorporated directly into your class design, forces the classes under test to have clean interfaces. User interface classes are sometimes harder to test using unit tests; for those areas, you may want to use an automation tool to script the user interface itself. If you are an iOS developer, you can use interface automation provided by the Instruments app; see Instruments User Guide . Depending on how you intend to use unit tests, you may write tests at different stages in your development process. For example, a common Agile practice, test-driven development, suggests that you never add new code to your app without first creating a failing test. Creating a failing test first helps ensure that the test is correct before writing the code. When using TDD, your test suite grows organically alongside your app and is refactored as you change your class interfaces and implementations. Other practices are possible as well. For example, if you are experimenting widely on the design and implementation of your app, you might not be ready to lock down the interface of a class until after a few iterations. In that situation, you may choose to design the tests after your class designs have stabilized somewhat. Implementing tests later may force you to make small changes to the class interface and implementation if you choose this strategy.
34
Developing an App Polishing and Testing an App
Polishing and Testing an App

After you implement your code, you need to test it to shake out bugs and other incorrect behaviors. And no matter how many unit tests you write or tools you use up front, you are going to run into bugs. But even more than that, there are other defects you want to look for. You want to ensure that users are comfortable with your apps behavior. You want users to feel confident that your app is well written and is protecting their best interests. The following suggestions have guidelines for polishing your app.
Test on Various Devices

Different kinds of devices have different capabilities; testing on more than one kind of device ensures that you are not making assumptions about how your app is going to operate. This step is particularly important when developing apps for iOS; Simulator is useful when developing your app, it has none of the performance characteristics or memory restrictions of the actual hardware. You need to put your app on actual devices and test it there.
Use the Archive Action to Create Test Versions of an App

The Xcode archive action allows you to build your app and store it, along with critical debugging information, in a bundle that is managed by Xcode. Archives are also used whenever you want to distribute your app, but they are also useful during development. For example, if you ship a test version of your app to testers, archiving the debugging information makes it easier to interpret crash reports that they send to you. When you are ready to make an archive, take this time to review the other build and compiler settings in your project. Important: Save the archive for any version of an app you distribute to users. You need the debugging information stored in the archive to decipher crash reports.
Use Instruments to Guide Your Efforts

The Instruments app, installed with Xcode, can be easily accessed through the Profile action in Xcode. Instruments is essential for learning how your app uses memory, how it uses the different subsystems of the operating system, and how well it performs under load. For an iOS app, Instruments can help you study how fast your app depletes a devices battery.
35
Developing an App Creating Great Apps
Ensure That Your App Meets the Approval Guidelines

If youve already archived an app and you are getting close to publishing it, you should use the Xcode Test action to verify the app. It tests a number of common problems that can immediately disqualify an app from being approved. In addition to using this automated test, you should also read over the guidelines and verify that your app follows them.
Creating Great Apps

Creating great apps is more art than science, but there is still plenty of science you can apply to improve the quality of your apps. In particular, by avoiding potential pitfalls, you avoid making an app that users dont like. Happy users often give apps a high rating on the App Store and recommend those apps to their friends. Here are a few areas you should consider at all points during the design and implementation of your app.
Design User-Focused Apps

When you design your app, focus on providing a great user experience. Avoid unnecessary interruptions or behaviors that prevent a user from performing tasks in your app. Focus on the idiom for the device your app is running on and tailor your apps interface to the users expectations on those devices. For example, although an iPhone has less screen space to display its user interface than other devices, another, more compelling, difference is the way a user interacts with an iPhone. A user may pull an iPhone out of a pocket to perform a short task, and then immediately put it backa very short interaction with the device. In contrast, an iPad not only has more screen space to display the user interface, but also users tend to use an iPad for longer tasks. A Mac has even more screen space and is likely to be used for longer still. When you design an iPhone app, you need to consider that a users interaction with your app is going to be brief, and thus interruptions may be perceived as more bothersome than they might be in an iPad or Mac app. By tailoring the experience to the OS and device and following Apples human interface guidelines, your apps should match up well with a users expectations.
Develop a Security Model

Security is essential to all apps and operating systems, particularly now. Devices are always networked, all the time. A compromised device may attempt to attack other devices. And security concerns go beyond attacks to take control of a device; users may store valuable personal data on their devices using your app. If a device is lost or stolen, users want to know that their data is safe.
Focus on the data: Examine how your app receives, stores, transfers and uses data. For example, if your app stores data in a file on an iOS device, that data is subject to inspection or modification when the device is backed up to iTunes. That data can then be synchronized back to the device and read back into your
36
Developing an App Creating Great Apps
app. Or, if your app receives data over a network, the data you receive from another entity might be a crafted into a malicious attack. Understanding how data flows through your app (and at what levels of trust) is critical to anticipating how your app may be attacked. Anticipating how your app might be attacked helps you design your app to detect and avoid these attacks.
Acquire only the minimum privileges to perform a task: A compromised app can do anything your app is permitted to do. On OS X, if your app performs tasks that require high levels of privileges, consider splitting your app into multiple processes and giving the secure privileges to a process that performs only those tasks. Another example of this principle is app sandboxing; sandboxing prevents other apps from accessing data files stored by your app. iOS apps are automatically sandboxed. On OS X, you need to explicitly implement sandboxing to protect your app.
Fail securely: If a task performed by your app might fail, always fail in a way that maintains the security of the device your app is running on and the users data.
Ensure Your App Runs Reliably

Make your apps as defect-free as possible. In the real world, errors happen all the time; your app must be designed and implemented so that it handles errors returned to it by the operating system. Heres a small subset of common errors your app must expect to happen at any time:
Network outages: Mobile devices often switch between networks or may be disconnected if the user moves away from a network hub or cellular tower. If your app requires networking, it must be prepared to be disconnected and reconnected at any time, even in the middle of a network operation. Running out of storage: Devices have a finite amount of storage; iCloud also places limits on the maximum amount of data your app can store in the cloud. Your app might exceed the storage limits when it attempts to write data to a file. Running out of memory: Devices also provide a finite amount of memory to your app. On iOS, if your app runs out of memory and is unable to free up memory when the system asks for it, it is terminated by the operating system. On OS X, you app may continue to run if it uses too much memory, but it runs slower and slower as it uses more virtual memory. Expect your app to run low on memory; it must be prepared to free up caches and other resources.
When considering the design of an app, always try to fail safely . Your app may be terminated because of a programming error on your part or an unavoidable condition (such as requesting memory when none is available and none can be freed by your app). It may even be terminated directly by the user. You want to make sure that the users data is not corrupted when your app is terminated. For example, one way to fail safely is to do all of the work necessary for a task without changing any of the existing data. Only after the task
37
Developing an App To Learn More
succeeds do you swap the completed work with the previous contents. This technique is often used when writing files to storage; write a new file, and then swap the data for that file with the data for the existing saved file.
Tune Your Apps Performance

An apps perceived performance is a critical part of its interaction with the user. An app that hangs on the launch screen or responds erratically to user input is perceived badly by users. More importantly, poorly performing apps are usually inefficient ; on mobile devices, inefficient apps consume more battery power and reduce the usable time of the device on a single battery charge. As you develop your app, consider these basic practices:
Understand which features must respond quickly to user requests: For example, an apps launch time is almost always something you should improve during the development process. Other critical tasks should always be performed quickly. When a task cannot be performed quickly, your apps user interface should provide some clue to the user that the task may take additional time. Tasks that cannot be performed quickly should not block the user interface; perform these tasks in the background instead. Fit your apps implementation to the problems it solves: The choice of classes you use (or algorithms you implement) should be based on the needs of your app. For example, theres a vast difference between an app that performs tasks on a dozen items and an app that performs tasks on millions of items. Match your design to the workload. Avoid premature optimizations: Avoid implementing highly complex algorithms or solutions until you are certain they are necessary for your apps actual performance. Instead, your early efforts should be to keep the design readable and understandable. Hide implementation details behind a clean class interface so that the implementation can be easily changed without requiring code dependent on that class to change as well. Ideally, so long as your unit tests continue to pass, you should always be able to change the implementation of a class to something more efficient without changing any other code in your app. Profile your implementation to discover where it spends its time: Often, the code that runs the slowest is not the code you expect to. The most reliable way to understand how an app executes is to profile it. Instruments provides many great profiling tools that you can use to understand the actual behavior of your app.
To Learn More
If you are an iOS developer, read the following documents:
Read iOS App Programming Guide to learn more about app programming on iOS. Read iOS Technology Overview to learn about the technologies that iOS makes available to an app.
38
Developing an App To Learn More
Read iOS Human Interface Guidelines to learn about how to make your app consistent with iOSs user interface conventions. Read Tools Workflow Guide for iOS for details about the tasks you must complete to develop your app.
If you are an OS X developer, read the following documents:
Read Mac App Programming Guide to learn more about app programming on OS X. Read Mac Technology Overview to learn about the technologies that OS X makes available to an app. Read OS X Human Interface Guidelines to learn about how to make your app consistent with OS Xs user interface conventions. Read Tools Workflow Guide for Mac for details about the tasks you must complete to develop your app.
Best Practices in Coding and App Design

Use these documents to help you improve the quality of your code:
Read Coding Guidelines for Cocoa to learn about the coding conventions used throughout Cocoa and Cocoa Touch. Using these same conventions in your own source code improves the consistency of your code. Read Secure Coding Guide and Security Overview to learn how to make your app more secure. Read Performance Overview to learn how to make your app more efficient.
39
Publishing an App in the App Store
After the last bug is fixed, the app is ready to ship. Now you need to get it on the App Store.
Administrative Configure the data in iTunes Connect Submit the app for approval Administrative and Coding Respond to customer issues
Ship it!
Configuring App Data in iTunes Connect

When an app is sold in the App Store, the store displays a lot of information about the app, including its name, a description, an icon, screenshots and contact information for your company. To provide that information, you log into iTunes Connect, create a record for your app, and fill in these items. The record in iTunes Connect includes a field for a bundle ID; the value you place in this field must exactly match the bundle ID for your app. Some Apple technologies, including Game Center and In-App Purchase, require that an iTunes Connect record be created earlier in the development process. For example, with In-App Purchase, you need to create the app record so that you can add the details of the items you want to sell. This content needs to be created before the development process is complete so that you can use it to test the code you added to implement In-App Purchase.
40
Publishing an App in the App Store Submitting the App for Approval
Important: Although you might need to create the iTunes Connect record before development is complete, you should delay this step as long as possible. Try to implement features that require an iTunes Connect record at the end of your development cycle. You must publish your app within a certain amount of time after you create an iTunes Connect record; if you exceed this time limit, the record is deleted from iTunes Connect, forcing you to create a new app record and reenter the data. The record is deleted to prevent unscrupulous developers from squatting on app names for long periods of time. The details are spelled out in iTunes Connect Development Guide. Alternatively, you might ship a version of your app without these features (thus avoiding the time limit) and implement these features in a later revision to your app.
Submitting the App for Approval

Near the end of your development time on your app, you started creating archives of your app. To recap, an archive includes a built version of your app and all of the associated debugging symbol information. When your team is ready to submit an app for approval, a team admin is going to perform two tasks on an archive youve created.
Your team admin uses Xcode to validate the archive. Validating an archive performs an automated check against the app in the archive as well as the information you provided in your iTunes Connect record. Your team admin uses Xcode to submit the archive for app approval. Xcode transmits the archive to Apple, where it is examined to determine whether it conforms to the app guidelines. For example, apps that crash or do not perform the tasks described in your iTunes Connect record are rejected.
If your app is rejected, correct the problems that were brought up during app approval and resubmit it.
Shipping an App
Use iTunes Connect to set a date when your app will be released to the App Store. For example, you can choose a date that immediately releases the app to the App Store after it is approved, or you can set a date sometime in the future. Using a later release date allows you to arrange other marketing activities around the launch of your app.
41
Publishing an App in the App Store Responding to User Issues
Responding to User Issues

Your work isnt quite done yet. You want to pay attention to how users perceive your app. Customer ratings and reviews on the App Store can have a big effect on the success of your app; if users run into problems, work quickly to determine the bug and submit a new version of your app through the approval process. The iTunes Connect site provides data to help you determine how successful your app is, including sales and financial reports, customer reviews, and crash logs submitted to Apple by users. Crash logs are particularly important, because they represent significant problems users are seeing in your app. Your team should make investigating these reports a high priority. Here are the kinds of crash logs you might see:
Application crash: An application crash is generated when execution is halted due to bad memory access, an exception, or some other programming error. Low memory: A low memory warning is generated when the app was killed by the system because there was not enough memory to satisfy the apps demands. User force-quit: A force-quit message is generated because your app became unresponsive and was quit by a user. Watchdog timeout: A watchdog timeout is generated when an app takes too long to launch, terminate, or respond to system events.
Except for low memory crash logs, all crash logs contain stack traces for each thread at the time of termination. To view a crash log, you need to open it in the Xcode Organizer. As long as your development computer has the archive corresponding to the version of the app that generated the crash log, Xcode automatically resolves any addresses in the crash log with the actual classes and functions in your app; this process is known as symbolication . This process is described in more detail in the workflow guides.
To Learn More
While designing and implementing your app, and definitely before submitting it to the app approval process, you should read the App Store Review Guidelines. If you are on an iOS team, these documents are your next steps to learn more about distributing your app:
If you are a team admin, read iOS Team Administration Guide . If you are a team member, read Tools Workflow Guide for iOS . Read iTunes Connect Development Guide for a comprehensive look at iTunes Connect and the tasks you perform there.
42
Publishing an App in the App Store To Learn More
If you are on an OS X team, these documents are your next steps to learn more about creating a team and setting up its signing certificates:
If you are a team member or a team admin, read Tools Workflow Guide for Mac . Read iTunes Connect Development Guide for a comprehensive look at iTunes Connect and the tasks you perform there.
43
Document Revision History
This table describes the changes to Developing for the App Store .
Date 2012-07-17 2012-01-09
Notes Updated artwork to show that the app ID prefix is always the team ID. This document was previously named App Development Overview. It now has a new title, new artwork, and many small clarifications and corrections. New document that describes the steps for developing iOS and Mac apps and submitting them to the App Store.
2011-10-12
44
Glossary
The glossary defines terms used in this document: app ID A unique digital fingerprint that grants your app access to a portion of the keychain; also, one part of a Development or Distribution Provisioning Profile. bundle A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code. bundle ID A string that uniquely identifies a bundle. code signing certificate An electronic document that associates a digital identity with other information, including a name, email address, or business. code signing identity The combination of a code signing certificate and its corresponding private key. A code signing identity is used to sign apps. Development Provisioning Profile A set of entities and entitlements allowing apps to be installed and tested on an development device. A Development Provisioning Profile consists of a name, a list of development certificates, a list of device IDs, and an app ID. development team A development team is a either a single person enrolled in the Individual Program or a team agent and group of team admins and team members in the Standard Program. distribution provisioning profile A set of entities and entitlements allowing apps to be distributed. A distribution provisioning profile consists of a name, a distribution certificate, and an app ID.
development signing certificate A code signing certificate restricted to app development. distribution signing certificate A code signing certificate restricted to app distribution. iTunes Connect A suite of web-based tools created for developers to submit and manage their apps for sale via the App Store. iOS iOS comprises the operating system and technologies that you use to run apps natively on iPhone, iPad, and iPod touch devices. Although it shares a common heritage and many underlying technologies with OS X, iOS was designed to meet the needs of a mobile environment, where users needs are slightly different. keychain A database used in OS X and iOS to store encrypted passwords, private keys, and other secrets. It is also used to store certificates and other non-secret information that is used in cryptography and authentication. source code repository A directory tree or database that contains the files managed by a source control system source control A set of tools and procedures for managing files and changes made to them over time. Also known as source control management (SCM) or version control. team agent The original person accepted into a developer program for all membership types. The team agent has access to all functionality in the Developer Program Portal and is responsible for accepting all developer program agreements.
45
Glossary
team admin A person on a development team designated by the team agent or another team admin who has all of the same privileges as team agents except for signing legal agreements. team member A person on a development team who can request development certificates and install apps on a development device. test-driven development (TDD) A programming practice that advocates writing a failing test case before changing the code in a project. When practicing test-driven development, you write a test case and ensure that it fails, then modify your code to make the new test (as well as previously written tests) pass. unique device ID (UDID) A 40-character string used to identify a specific iOS device. unit test A piece of code that exercises some part of your app. A unit test provides a specific input and expects your code to return a specific output. Xcode Apple's development environment for OS X and iOS; it includes all the tools needed to create, debug, and optimize OS X and iOS apps. Xcode project A group of source files, libraries, media, and other resources needed to build your product.
46
Apple Inc. 2012 Apple Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, electronic, photocopying, recording, or otherwise, without prior written permission of Apple Inc., with the following exceptions: Any person is hereby authorized to store documentation on a single computer for personal use only and to print copies of documentation for personal use provided that the documentation contains Apples copyright notice. No licenses, express or implied, are granted with respect to any of the technology described in this document. Apple retains all intellectual property rights associated with the technology described in this document. This document is intended to assist application developers to develop applications only for Apple-labeled computers. Apple Inc. 1 Infinite Loop Cupertino, CA 95014 408-996-1010 Apple, the Apple logo, Cocoa, Cocoa Touch, Instruments, iPad, iPhone, iPod, iPod touch, iTunes, Logic, Mac, Objective-C, OS X, and Xcode are trademarks of Apple Inc., registered in the U.S. and other countries. iAd and iCloud are service marks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc. OpenGL is a registered trademark of Silicon Graphics, Inc. iOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used under license.
Even though Apple has reviewed this document, APPLE MAKES NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS DOCUMENT, ITS QUALITY, ACCURACY, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS DOCUMENT IS PROVIDED AS IS, AND YOU, THE READER, ARE ASSUMING THE ENTIRE RISK AS TO ITS QUALITY AND ACCURACY. IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT OR INACCURACY IN THIS DOCUMENT, even if advised of the possibility of such damages. THE WARRANTY AND REMEDIES SET FORTH ABOVE ARE EXCLUSIVE AND IN LIEU OF ALL OTHERS, ORAL OR WRITTEN, EXPRESS OR IMPLIED. No Apple dealer, agent, or employee is authorized to make any modification, extension, or addition to this warranty. Some states do not allow the exclusion or limitation of implied warranties or liability for incidental or consequential damages, so the above limitation or exclusion may not apply to you. This warranty gives you specific legal rights, and you may also have other rights which vary from state to state.

Application Development Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Development Overview

Uploaded by

Copyright:

Available Formats

Developing for the App Store

About the Application Development Process 5

Building an App for the App Store 8

Preparing the Development Team 10

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Distributing an App Requires a Distribution Profile 28 To Learn More 28

Publishing an App in the App Store 40

Document Revision History 44 Glossary 45

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Figures and Tables

Building an App for the App Store 8

Preparing the Development Team 10

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

About the Application Development Process

Developing for Apples Platforms Is a Mix of Administrative and Coding Tasks

Apps Published on the App Store Must Be Approved by Apple

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

About the Application Development Process At a Glance

Relevant Chapters: Publishing an App in the App Store (page 40)

Apps Published on the App Store Must Be Cryptographically Signed

The Majority of Your Coding Time Is Spent in Xcode

Administrative Tasks are Performed with Several Resources

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

About the Application Development Process How to Use This Document

Many Behaviors of an App Are Defined by Data, Not Code

How to Use This Document

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Building an App for the App Store

Develop the app

Prepare the Development Team

Configure the Project

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Building an App for the App Store Develop the App

Develop the App

Publish the App in the App Store

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team

Add members to the team

Enrolling in an Apple Developer Program

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Adding Members to a Team

Adding Members to a Team

Understanding Membership Privilege Levels

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Adding Members to a Team

Table 2-1 Role

Team roles Description

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Organizing the Team in iTunes Connect

Organizing the Team in iTunes Connect

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Organizing the Development Team

Organizing the Development Team

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Organizing the Development Team

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Organizing the Development Team

Source code server

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Creating Your Teams Signing Certificates

Creating Your Teams Signing Certificates

An Example: Signing an iOS App During Development

2012-07-17 | 2012 Apple Inc. All Rights Reserved.

Preparing the Development Team Creating Your Teams Signing Certificates