Professional Documents
Culture Documents
Contents
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
Contents
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
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
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.
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.
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)
iOS: Start Developing iOS Apps Today OS X: Start Developing Mac Apps Today
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
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.
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.
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
10
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.
11
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
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
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
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
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
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
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.
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.
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
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
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
22
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.
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
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.
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.
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 *
Bundle ID search string (determined by Developer)
A1B2C3D4E5comdomainname *
Bundle ID search string (determined by Developer)
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
comotherdomaindatabase
comdomain
If an app ID uses an asterisk (*) as the bundle ID, then the search string matches any bundle ID.
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
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.
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
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
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
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
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.
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
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.
33
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.
34
35
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
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.
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
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.
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
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.
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.
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
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!
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.
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
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
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
This table describes the changes to Developing for the App Store .
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.