Learning iOS Development: A Hands-on Guide to the Fundamentals of iOS Programming (2014)
Chapter 15. Deploying Applications
The CarValet app is complete, performance is perfect, and the bugs have been found and squashed. Now you are ready to show your app to the world. Or are you? Ready on your machine is not necessarily App Store-ready. You need to take a few more steps before uploading your app.
In this chapter, you learn how to take your app from the simulator to the App Store. You start by learning about certificates, profiles, app IDs, icons, and launch images. Then you explore all the things you need to do before launch: doing better bug reporting, adding metrics, doing internal and external testing, and preparing for marketing.
Next, you learn the details of creating an app listing, uploading your app, and making it available, as well as some things to watch after the launch. The chapter ends with some pointers on where to go next.
Before you read any further, there is one very important thing you need to understand: Apple regularly changes things. Sometimes it makes small changes and sometimes significant ones. For some parts of this chapter, especially the section “Uploading and Launching,” you can’t rely completely on the screenshots. Focus is on the general process flow, along with the kinds of information you need to provide. This chapter gives you some idea of what the information is for and, where possible, guides you on how to craft it. When you get there in a few pages, make sure you read the “Caution: Sizes, Requirements, and Processes Change.”
Certificates, Profiles, and Apps
To add an app to the App Store, you need to have six things in place:
An Apple iOS developer account.
Your distribution certificate and the associated private key.
A development provisioning profile for installing your app on devices used for creating the app. (As you soon see, Xcode generates this for you as part of the certificate process.)
An app ID you create with associated provisioning profile(s). (Again, Xcode can generate the profiles for you.)
A distribution provisioning profile for your app.
A profile for your app created in iTunes Connect.
Chapter 1, “Hello, iOS SDK,” covers the different types of developer programs and registration. The next step is to generate a development certificate, a digital document used to uniquely identify you and your developer account/company. Note that you need to be a member of a paid developer program to do this.
A certificate is like an electronic car key. In addition to locking and unlocking the car, the key has a unique wireless code that is required for starting the car. Each code is unique to one car. You could not use your key to open and start someone else’s car. Unlike car keys, certificates are used to generate, or sign, other forms of identification. A certificate can create a key for each of your cars.
A certificate has two parts: a private key that only you have and a public key that anyone can have. Signing uses your private key to generate a new key, based on some input. For apps, the input is the private key, app ID, and some other info, and the output is a provisioning profile. Code takes this provisioning profile and public key from your developer certificate and determines whether the profile is valid. Apple uses this to check whether an app should run on a device.
In other words, the private key is used to sign things, and the public key is used to check if it was really you that signed them. Your private key is a digital you, and should be protected. Anyone who has that key can create apps that appear to be from you. In addition, you need to make sure to back up your private key and keep it somewhere safe, such as an encrypted disk or partition. If you lose it, there is no way to regenerate it. You would have to generate a new certificate with new private and public keys, and all existing provisioning profiles would be invalidated (though any currently shipping applications using the old distribution profile will still work).
Caution: Sizes, Requirements, and Processes Change
The one constant in life is change. This applies to registration of app IDs, required icon sizes, default images, and even app submission. When Apple introduced iPhone 4, icon sizes changed. The same happened with iPhone 5 and the third-generation iPad with retina display. When submitting an app, the age rating was not always as detailed as it is now, and even registering an app ID changed when Apple introduced an updated developer portal.
Before you prepare and submit an app, it is a good idea to check the latest requirements in two very important documents. Both are available in Xcode as well as on the web.
For icon sizes, launch images, and similar things, check the iOS Human Interface Guidelines. In fact, read these guidelines regularly as they distill Apple’s hard-won design knowledge in a form you can use to create better apps. In addition to the version in Xcode, you can find the latest version on the web at https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html.
For information on registering an app ID or uploading an app, see iTunes Connect Developer Guide. Again, this is available in Xcode, as a link on the home page of iTunesConnect.apple.com, and on the web athttp://developer.apple.com/library/mac/#documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/1_Introduction/Introduction.html.
Whether you are working with your first, fifth, or fiftieth app, checking these resources before you get too far can save you a lot of time and effort.
Generating a Development Certificate and Profile
Although generating certificates and profiles sounds like a complex process, it is easy to do and, in fact, Xcode can do most of the work for you. This is because you tell Xcode about your developer account (or in some cases, accounts) using the Accounts pane in Preferences, as shown inFigure 15-1.
Figure 15-1 Accounts preferences pane
When you click the + button, you are prompted to enter the Apple ID and password used for your developer account. If you have not yet joined a program, you can click the Join a Program button and be taken to the signup page in Safari.
When you add a profile, the Accounts pane looks something like Figure 15-2. The next step is generating provisioning profiles, unless you already have some. If not, select your account in the right-hand column of the Accounts pane and then select the correct account member in the lower right. If you are an individual developer, there is only one.
Figure 15-2 One developer account
The iOS column shows the role each member plays and is only important if you are using a company account or are part of some other team. The important thing is for the role to have permission to generate whatever kind of certificate or profile you need. This book assumes an individual account where you are the Agent, someone with full permissions.
With your role selected, click the View Details... button on the lower right. This brings up a window showing the associated signing certificates and provisioning profiles. To have Xcode generate certificates, press the Refresh button in the lower left. Shortly thereafter, another popover opens, enabling you to request both development and distribution certificates. Figure 15-3 shows the popover.
Figure 15-3 Requesting certificates
After a few moments, the spinner in the lower left stops and you see your certificates appear. Xcode has done all the work for you, including creating a private key. Better still, provisioning profiles are created at the same time.
Adding Devices to a Provisioning Profile
Provisioning profiles let you run development code on devices. If you try to run development code on a device that is not registered with your developer account, it will not work. Profiles contain a list of valid devices. If a device is not on that list, nothing works.
Adding a device takes only a few steps:
1. Plug a device into your machine using a USB cable.
2. Open the Xcode Organizer window, either from Window > Organizer, or by pressing Cmd-Shift-2. You see a window like that in Figure 15-4.
Figure 15-4 Enabling a device for development from the Xcode organizer
3. Select the device you want to add to your developer account.
4. Click the Use for Development button.
5. In the dropdown that appears, select the appropriate development team and press Choose.
Xcode now registers the device and regenerates your development profile. With a generic development profile, you can work on any app and have multiple development devices. With a distribution certificate, you can create, or sign, a profile for app distribution. Doing that requires an app ID.
App ID and Provisioning
A distribution provisioning profile is required for any beta/testing version you want to distribute more broadly, as well as for the final app. Generating the profile requires a distribution certificate, an Apple intermediate certificate (Xcode downloads that when certificates are generated), and an app ID. For test or ad hoc profiles, you also need a list of IDs for devices that you want to run the app.
You have the certificates, so now you need an app ID, which needs to be unique to your company and possibly to the app. Whether you need an app ID that’s unique to the app depends on whether you are planning to use, or in the future add, any Apple services: in-app purchase, iCloud, push notification, game center, data protection, or passes. The safest choice is to use a unique ID for each app, which gives you the choice of adding services later.
Generating an App ID
Before you create an app ID, you need to know the bundle identifier for the app. This is a string in the form com.domain.appname. You can find the current bundle identifier by looking at the general tab for the project target in Xcode. It is at the top, though the final string in the profile is usually shown grayed out.
If you do not need Apple services, you can create a generic ID by using an asterisk (*), instead of appname (that is, com.domain.*). You also need a text name to associate with the ID. This is important because portal operations such as creating a provisioning profile use this name, not the ID string. When you know this information, follow these steps:
1. Log in to your Apple developer account.
2. Click Certificates, Identifiers & Profiles in the upper right.
3. In the portal, select Identifiers. Here you should see a list of any existing IDs. This is also where you add Apple services.
4. Click the + button in the upper right. This takes you to the screen shown in Figure 15-5.
Figure 15-5 Creating a new app ID
5. Enter the text name you chose earlier into the App ID Description field.
6. Choose any services your app uses.
7. If you need Apple services or you want a fully specified bundle ID, select Explicit App ID and type in the bundle name. Otherwise, select Wildcard App ID and enter the wildcard string.
8. Click Continue, check the details on the summary screen, and click Submit. Your app ID is created.
When you return to the app ID overview in the portal, you see the newly created ID.
Creating the App Distribution Provisioning Profile
Now that you have an app ID, the next step is to create a distribution provisioning profile. There are two types of profiles: ad hoc (or testing) and App Store profiles. You will use both of them. The ad hoc profile requires more information, so start there, with these steps (and remember, things might change):
1. Open the Certificates, Identifiers & Profiles area for your developer account and select Provisioning Profiles.
2. Click the + button and then select Ad Hoc, as shown in Figure 15-6.
Figure 15-6 Creating an ad hoc profile
3. Click Continue, select the appropriate app ID from the list, and click Continue again to go to the next screen.
4. Select the distribution certificate for this app. Most of the time there is only one. Click Continue to go to the next screen.
5. Now select any testing devices. It helps to prefix testing devices for easy organization. For example, you can use P for personal, F for friend, or even codes for projects or apps. Click Continue to go to the final screen.
6. Name the profile something meaningful, such as <TYPE> <AppNameGoesHere>. For example, you could use AdHoc CarValet. Now click Generate.
7. Switch to Xcode and refresh your Provisioning Profiles the same way you did when creating your developer certificates. Refer to Figure 15-1.
If the new profile is not in the list, wait a few minutes and then refresh again. The Library area then includes the new profiles. Figure 15-7 shows an example.
Figure 15-7 Xcode Provisioning Profiles
There are three columns of information for each provisioning profile. First is the name, which corresponds to the original profile name field. Next is the profile Expiration date. And finally are any Entitlements associated with the profile. The entitlements are represented with the same icons used in the Capabilities tab for a target in Xcode. As an example, the last provisioning profile has three icons: The first is iCloud, the second is App purchase, and the third is GameCenter.
Generating a profile for the App Store is almost identical to generating an ad hoc profile, except you choose App Store in step 2 and do not need to specify testing devices (step 5). You are almost ready to build a distributable test app. First, you need to add some artwork.
Tip: What to Do When Things Go Wrong
Since I started development for iOS in 2009, I have encountered numerous problems with invalid/missing distribution certificates, inability to generate provisioning profiles, and related issues that bring on, as Erica calls it, “the yellow triangle of doom.”
The first lesson I learned from all these occurrences (not to mention a love of British satirical sci-fi and fantasy) is “Don’t panic.” Usually the Xcode error will provide you all the information you need to fix the error. And if not, there are several things you can try, and there are places you can look to ask questions and get answers.
Surprisingly, one thing that sometimes works is “Do it again.” Deleting everything in the profile library and using Refresh causes Xcode to go through all the steps, including ones you might have accidentally skipped.
If that does not work, here are a few things to try:
Clear the list and then quit and reopen Xcode. Now click Refresh.
Clear the list and quit, but this time restart your machine before relaunching.
Clear the list, launch the Keychain application, and use the Keychain First Aid option. When the keychain is cleaned up, try Xcode again.
If you’re working on a new Mac, check whether you transferred both your public and private keys for your developer certificate. Of course, I always do this...well, usually.
Use the Keychain application to make sure you have the required private keys. If not, add them or generate new certificates.
Log on to the developer portal and check your certificates and profiles online. If they are there, you can manually download them. If not, and if Xcode is not cooperating, you can generate them using the portal.
If all this fails, you can go to the Apple developer forums. Look for similar problems or ask a question. You can also check with fellow developers and/or your local iOS/Cocoa developer group. Searching the web is another option. Use the resources at the end of this chapter as a guide for where to look.
And, as mentioned earlier, if all else fails, you can always regenerate your certificate. It means you need to regenerate your profiles, but at least you can get back to work.
Icons and Launch Images
Before you can distribute a test build, you need the required set of icons and launch images. Not every icon size and image is required; you need only those for the categories of devices and the orientations you support.
Except for the iTunes store artwork, the easiest way to check if you have all the images you need is by opening Images.xcassets and checking the AppIcon and LaunchImage items. Each one has slots for each icon size or image size you need.
Each item lists the kind of image (for example, iPhone App) as well as a point size. Because images are square, the point size tells you the width and height. Launch images list what screen they are for and in some cases which orientation, but they do not list sizes.
Table 15-1 shows the various images and sizes. Nonretina sizes are listed, though as of the writing of this book, the original iPad mini is the only iOS 7 capable device with a nonretina display.
Table 15-1 Sizes for Icons and Launch Images
In general, the names of the app icon or launch image files do not matter. The asset catalog manages that for you. Having said that, it is a good idea to use a convention to easily identify the target resolution of the image. Typically, an image with no special resolution or targeting an asset catalog 1x slot uses the plain image name. If it is for a 2x slot, the name is appended with @2x, and the R4 slot can use @R4. As an example, if the base image file is MyLaunch.png, that is the name for 1x resolution images; MyLaunch@2x.png is for 2x, or retina, slots; andMyLaunch@R4.png is for slots using R4. (Note that the iOS 6 version of this name would be MyLaunchfirstname.lastname@example.org.)
The iTunes icon name is iTunesArtwork.png.
Adding App Icons
Open the project you used for Chapter 14, “Instruments and Debugging,” or use CH15 CarValet Starter provided in the sample code for this chapter. Follow these steps to add in the app icons:
1. Open Images.xcassets in the project, and then choose AppIcon. You see a set of empty asset bays shown on top in Figure 15-8.
Figure 15-8 Adding app icons with the asset catalog
2. In the Finder, open the folder CH15 Assets App Icons that comes as part of the sample code for this chapter. Select all the icons and drag them into the area with the empty assets. When you see some of the empty icon bays highlight, drop the icons. The area should look something like the bottom of Figure 15-8.
3. If all the icons for iOS 7 are not complete, drag in any remaining icons individually. In the bottom of Figure 15-8, the 2x iPad settings icon is missing. Drag Settings@2x directly into that box.
Run the app on different simulated screen types: iPhone (retina), iPad, and iPad (retina). For each device type, close the app and look at the icon. It will be the right size for that device. (If the new icon does not appear, you might need to clean the build by pressing Shift-Cmd-K and then the build folder by pressing Option-Shift-Cmd-K.)
After the user launches an app, it takes a bit of time before you can make any changes on the screen. During this time, the system shows the launch image. The default launch image is black and not very interesting.
Existing apps’ launch images do everything from promote a brand to show a blank interface. Apple currently recommends showing the main screen of your app with no details. Spend some time launching applications making sure they are removed from device memory to see what other developers use for launch images. For CarValet, you use a variant of the no detail image from the iPad combined with the car from the app icon. Follow these steps:
1. Open LaunchImage in the Images.xcassets.
2. In the Finder, open the CH15 Assets Launch Images folder that came with the sample code.
3. Bring Xcode back to the front and make sure you can see the contents of the assets folder. Then drag each named image into the appropriate bay.
Now that you have a default launch image and icon, the next steps are to add some important extras to your app, do some external testing, and start marketing activities.
Before your app is App Store-ready, you need to take care of four important details:
Add bug reporting to your app.
Include metrics gathering.
Test with a wider audience.
Start marketing activities. (Yes, this soon...and you should probably start sooner next time.)
All these processes could be done earlier in the development process, but not too early. Bug reporting can wait until you start outside testing. You can add metrics from the start. You usually wait to start outside testing until you have a solid beta. Marketing can make a huge difference in downloads, and even if you have existing customers, you still need to reach them.
The sad fact is that bugs make it into shipping apps. It’s important to quickly catch and fix the ones in your shipping app that cause crashing and noncrashing exceptions. You can look at crashes by using iTunes Connect, but the data is limited and not well presented. What you really want to know is what crashes occur, how often, and on what device/OS, and you want a full stacktrace.
A few companies offer drop-in solutions with associated web services. Their software catches exceptions, anonymizes them, and reports to a server. You log on to their server and get the data. Solutions vary from do-it-yourself to full analytics, including seeing the steps that lead to the crash.
Most services are based on the open-source Plausible Crash Reporter project found at http://code.google.com/p/plcrashreporter/. You can use the code to capture bugs in your app. However, you need to create a back-end server and handle uploading bugs, along with many other details.
It is much faster to use an existing service. Most are free for basic reporting and then vary in cost, depending on features and/or number of incoming reports. The following are some of the existing major companies, in alphabetical order (see the “What Do You Use?” sidebar later in the chapter):
pulse.io (performance only at this time)
All the third-party bug-tracking software works basically the same way:
1. Go to the company’s site and create an account.
2. Download the SDK.
3. Add the SDK to your app by following appropriate instructions. You usually need to add a static library to your project.
4. Include the company header in your app delegate, call a routine to start tracking and, optionally, set up more data and make more specific calls.
In addition to bug reporting, companies are starting to offer performance metrics including CPU use, memory, battery and, most importantly, network. Because so many apps rely on the network, knowing which performance issues are your app and which are the network is critical in tuning your product. And you can only do that with the kind of data you get after the app is shipped. One of the companies mentioned previously specializes in performance, though others in the list also offer services.
As you can see, adding reporting takes very little effort. Some providers have other calls you can make to send more details or even send custom reports. A few offer built-in user feedback and even communication to let a user know his or her bug has been fixed.
Note that it is up to you to make sure whatever you include does not violate any personal privacy information laws or your own app’s statement of information use. See “Warning: Beware of Ever-Changing Privacy Laws” later in this chapter.
Warning: There Can Be Only One (Active Bug Reporter)
As mentioned, most, if not all, of the bug-reporting libraries use the open-source project for reporting exceptions. Because of the way PLCrashReporter works, there can be only one bug reporter, even if multiple services try to use it. If you use three services (for example, metrics, testing, and bug reporting), and all three can report bugs, only one will. And it might not be the bug-reporting service.
And these days everyone is offering to report bugs. For this reason, it is important to make sure any third party service has an option to turn off bug reporting. And not just preventing the bug report, but also stopping their library from initializing PLCrashReporter. If not, you might end up paying for a bug-reporting service that is never called.
The App Store gives you some information about your shipping app: the number of downloads and updates, user ratings, app rank, and a few more metrics. But the data can be hard to consolidate. And it does not tell you much about what users are doing or whether they are coming back to your app.
There are a few key questions in tuning your app:
Are people downloading and using your app (first-time use)?
What is the typical time using the product (engagement)?
Are users staying around (retention)?
What features are they using and not using (tuning the product)?
Are they using new features (more product tuning)?
Are certain locales adopting your app more quickly or slowly than others?
For those paying for ads, which ads are working?
You can collect metrics yourself, but it takes a lot of effort. It requires capturing and sending data to a server, and you need software to analyze the data. Luckily, several companies offer plug-and-play solutions. You register on a site, add a library, make a call at app start, and the numbers start rolling in.
As with bug tracking, there are numerous providers in the metrics arena, though unlike with bug tracking, most are free. These companies are in the business of selling anonymous consolidated data, and your app provides just a small part of that data. Some companies also sell advertising, and others want you to advertise with them. Some of the large providers include other features (see the “What Do You Use?” sidebar later in the chapter). Check out the following companies that are active in the metrics space:
Adding a metrics library is almost identical to adding a bug-reporting library. Unlike with bugs, you are highly likely to make many calls for different types of user events. Some services automatically capture moving from app screen to app screen. But that does not tell you what the user does on a particular screen.
Warning: Beware of Ever-Changing Privacy Laws
Any services, including metrics, bug reporting, and even ads, might capture some sort of PII: Personal Identifying Information. Protecting this information has become a priority in some countries and is currently the law in the European Union. If you use any services, make sure their use of such information (and yours) complies with the laws of any country where you distribute your app as well as your app’s own privacy agreement.
If you are not a lawyer, you can either accept the provider’s assurance they comply, or you can hire your own lawyer to make sure. Breaking privacy laws can have serious consequences.
Quality Assurance Testing
There are many types of QA (quality assurance) testing, though for your purpose, you can focus on three: unit testing, automated functional testing, and integration testing.
Unit tests are usually created by the person writing the code, and they test that a particular feature performs as expected—for example, that correct input works and gives the right result and incorrect input fails appropriately.
Xcode comes with a unit-testing framework that is added to projects by default (at least as of the current Xcode 5 beta). With the addition of a Mac OS X server, you can run sophisticated continuous integration using unit tests and other tools such as static analysis. This is a powerful tool in finding problems while they are still small.
Functional testing checks that your app behaves as it is supposed to—for example, that touching buttons does the right thing, scrolling tables work, and proper errors are shown. This kind of automated testing can only test what you expect to happen and always in the same way.
Unfortunately, the existing Xcode automation tools do not support calls to the interface or communications layers. There are tools in Xcode for interface testing but they are quite limited. Many frameworks are available for automated interface testing, usually based on public domain frameworks. TestStudio from Telerik provides a professional solution, but there are costs for serious use.
Integration testing is done by real people trying to use your product, usually in ways you do not expect. Lack of this kind of testing is the source of most serious postshipping bugs.
Unit and Functional Testing
Other providers use different languages and require different amounts of work. As of this writing, for functional testing, TestStudio by Telerik is the one best integrated with the Apple Objective-C-based unit test framework. Table 15-2 lists some of the many providers. (See the “What Do You Use?” sidebar later in the chapter.)
Table 15-2 Unit and Functional Testing Solutions
There is nothing like having real people test your app. It is the best way to discover memory and sequencing problems. It is also where you discover how customers really use your app.
Finding people to test your app can be challenging. Ideally, testers should know how to push your app to the limit and how to report bugs. It is possible to do integration testing on your own, if you do the following:
Recruit testers who have either Xcode and a simulator, or a device.
Set up an appropriate ad hoc provisioning profile that includes all the device IDs and distribute credentials for those using simulators.
Build and distribute test (AdHoc) app versions, making sure testers keep up to date.
Coordinate all the feedback and bug reports.
This is a lot of work, especially if you have no one else to do it for you. And that is where the various service providers can help. They vary from enabling easy distribution to doing the testing for you. Table 15-3 lists a few services. (See the “What Do You Use?” sidebar.)
Table 15-3 Ad Hoc Testing Providers
One important thing to remember is that as a developer, you can only register a limited number of unique developer/testing device IDs in any one membership year. At this time it is 200, so if you had 199, added 1, and then removed 3, you would still have no new testing device slots until the beginning of your new membership year.
What Do You Use?
One question I get on a regular basis is “What service do you use?” The answer depends on the business importance of the app. If the importance is low, any of the free services will do, though Flurry offers both metrics and simple bug reporting.
For bug reporting and performance, it depends on the type of app. Assuming the revenue model supports it, Crittercism provides a well-rounded solution with both bug reporting and performance monitoring. For the more cost-conscious projects, a combination of Crashlytics and either New Relic or pulse.io can give you what you need.
No matter which service you use, you get data on bugs such as device type and OS, symbolicated stacktrace, frequency, custom metadata, and more. Some services offer breadcrumbs—that is, how the user got to the bug. Those can significantly reduce the amount of time to reproduce, and therefore fix, the bug.
For metrics, I like Flurry, for its in-depth analysis. And even though there appear to be limits on the number of cohorts (used for retention), a quick conversation usually results in the needed changes (though again, make sure this makes sense from a business/revenue perspective).
For unit and functional testing, I use Telerik’s TestStudio. Scripting makes repetitive functional testing a breeze both in the simulator and on devices. And integration with Apple’s UnitTest framework makes developer-driven and continuous integration testing easy, though this soon might require something like Jenkins (see later) to get working.
For early/alpha stage user testing, I think it’s a toss-up between TestFlight and HockeyApp. Both are easy to integrate, make distribution easy, give access to a pool of testers, and have feedback mechanisms. For more important apps that require the human touch, usertesting.com is my service of choice based on the quality of service and its experience in mobile. (One of the founders used to work for Palm.)
One service not mentioned is the idea of continuous integration testing during development. The idea is to have automated testing as you build new versions of your app. Jenkins lets you do that and a lot more. When you have a build server set up, you can configure it to automatically build and run unit tests any time you check code into your source code repository. And Jenkins can do a lot more. Note that a build server can be the same machine you are using, though this is not recommended for teams. To find out more, visit their website: http://jenkins-ci.org.
Cloud storage and sharing is a service that is not really covered by this book but is becoming increasingly important. Apple provides a way to save Core Data into the cloud as well as game services through GameCenter. For a more general solution, I have found Heroku,https://www.heroku.com, a good place to start (and more), though there are several providers, some of whom have a strong client list (Parse, StackMob, and the Google cloud platform).
One extremely important service not mentioned is source code control. There is nothing worse than trying to fix an issue, discovering the change is much worse, and wanting to revert to the old code. Source code control lets you save incremental changes and go back to previous versions. I have used both SVN and Git, and all my source is stored somewhere in the cloud. GitHub is the standard place for public domain code and offers both free public and for-cost private storage.
Of course, over time, providers change. It pays to keep watching the various providers, old and new.
Marketing can make the difference between a few downloads and thousands. There is no secret formula that guarantees success, but there are things you can do to increase your chances. Although marketing is covered in prelaunch, it really spans the lifetime of your app.
Before launch, the focus is on building infrastructure and interest. Infrastructure adds app functionality for easy rating and tell-a-friend functionality. Word of mouth can be a powerful and low-cost marketing tool.
There are many open-source projects for reminding a user to review and tell their friends. You can use them directly or as a basis to write your own. (And remember to contribute back if you make it better.) These are a few of the common ones:
Interest is about contacting press, bloggers, and others who can increase awareness of your app. Remember that these people have thousands of developers contact them each day. You have a few words or perhaps an image or two to catch their attention. If you do, you get more time, but even that does not guarantee coverage.
Some very useful apps let people play with your app via the web. This can be a useful tool for marketing, though you need to make sure there is not too much utility, or why would they buy the app? One such tool is app.io, though others are appearing.
When your app ships, your listing is critical. It is the first thing a user sees.
A full treatment of marketing is beyond the scope of this book, but there are many books on marketing, covering everything from general principles to iOS-specific marketing. Here are a few to get you started:
iPhone and iPad Apps Marketing: Secrets to Selling Your iPhone and iPad Apps, second edition, by Jeffrey Hughes
Pitch Perfect: The Art of Promoting Your App on the Web by Erica Sadun and Steve Sande
And since you are likely to need an app/company website: The Ultimate Web Marketing Guide by Michael Miller
Uploading and Launching
Your testing is done, your app is wired for bug reporting and metrics, and you are executing your marketing plan. The time has come to upload the app...almost. Before you do that, you need to create an app listing.
Remember that things change. April 2013 saw a complete redesign of the portal for accessing certificates, app IDs, profiles, and test devices. June 2013 streamlined certificates, profiles, entitlements, and other things with Xcode 5. It is only a matter of time before more updates occur. This section describes the flow involved in updating and launching. The screenshots were taken when this book was written. Tomorrow’s websites could be different. Make sure you read the “Caution: Sizes, Requirements, and Processes Change” at the beginning of this chapter and keep an eye on the two important documents it talks about.
First, you need to add an entry for the app in the App Store:
1. Log in to https://itunesconnect.apple.com using your developer account e-mail and password.
2. If you have not already done so, sign the legal agreements that appear.
3. If you are going to sell apps, allow in-app purchase, or use iAd, Apple’s ad framework, set up payment accounts. If you need to do this and you are not taken to that area when you log in, from the home screen go to the Contracts, Tax, and Banking section and provide any required information.
4. From the home screen, go to Manage Your Applications.
5. On the Manage Your Applications page, add a new app. You are prompted for the key app information. Figure 15-9 shows how this screen might look for the CarValet app. The alert in Figure 15-9 lets you know the bundle ID cannot be changed when the app is accepted or if you have set up Game Center. You need to make sure the app ID works for the entire life of the app. iOS uses the ID to uniquely identify an app, as well as associate it with data and settings. If you change the ID, there will seem to be two copies of your app on a device: one with all the old data and one without.
Figure 15-9 New app page
6. Choose the name for your app that will appear at the App Store. This is a really important choice. Make sure you do not use an existing trademark or conflict with any existing app names. You have up to 255 characters for a name that makes a user want to get your app, or at least look at the listing for more information.
7. Set the stock-keeping unit (SKU) number to whatever you want it to be. Apple does not use it; it is for you.
8. When you are done setting the main app details, choose when the app launches, how much it costs, and decide whether to limit it to certain countries. Figure 15-10 shows how this screen could look.
Figure 15-10 Launch date and price
The availability date is a guideline, and the actual date depends on when your app is reviewed and approved. As of this writing, the average time was about 1.5 weeks, though the time can vary widely. One source to check is http://reviewtimes.shinydevelopment.com. It shows a 30-day rolling average review time. Also note that the current developer program lets you request an expedited review once a year. This is not something to use lightly. Save it for a critical bug fix. When you use it, it is gone for the year...and “pretty please” does not work.
When picking a date, it is best to choose one at least a few months in the future, so you have control of the actual release date. When your app is approved, you can set up any required press activities and update the actual release date accordingly. When you start uploading updates, there is an option to hold the approved app until the developer releases it.
After you have set what, when, and how much for your app, you need to enter all the details needed to list and review your app. You need to worry about lots of pieces of information, starting with the version number, copyright holder and, most importantly, the category. Figure 15-11 shows the part of the page currently used to enter this information. (This is one of the most-likely-to-change pages.)
Figure 15-11 Choosing the primary app category
Choosing the right category makes a huge difference in the number of downloads. Customers use it as one way to filter what they look for. You can optionally choose a secondary category, but make sure your primary choice is the one users expect. Ask your possible users questions if you are not sure. Do some A/B testing.
After the category, you need to set the age rating. You need to tell users what kind of content your app contains in a number of different areas; Apple uses things like the amount of violence, horror, and alcohol use to set the rating, as shown at the top of Figure 15-12.
If your app is aimed at kids, make sure you check the Made for Kids box.
Figure 15-12 Content rating and metadata
Figure 15-12 also shows other important app information that is currently grouped under Metadata.
When you attract a user to your listing, the description has a strong influence on downloads. You have about three to five words to catch a potential user’s attention and get the person to read more. And you need to keep the user engaged. Strike a balance between inviting and/or exciting prose and feature facts. Focus on why the app is valuable for the target audience. What problem does it solve? How will it make life better? Good marketing books and competent marketing consultants are worth their weight in gold.
It’s a good practice to start reading through app descriptions. See which ones grip you and which ones make you want to move on. Look for patterns. For example, asterisks, pluses, and other characters can draw attention to key points when they are used sparingly. Conversely, listings using lots of long lines of these characters are distracting at best and deadweight at worst. The same goes for blasting the user up front with tons of reviews about how great the app is.
Keywords are another strong influence. When users search the App Store, keywords play, well, a key role. Unfortunately, Apple does not disclose precisely how they are used. There are people who specialize in optimizing keywords. These folks can be valuable. However, be aware that Apple is continuously tuning their algorithm. Optimization does not happen once. It is ongoing. A good sign something has changed is unusual trends in downloads.
The spaces for listing URLs give you a chance both to give more information and show that yours is a serious business. A company website with a section dedicated to the app, information on the company, as well as professional-looking support, can indicate a trustworthy company. You could use a service like Zendesk (www.zendesk.com) to add depth to app support.
The final part of the page, shown in Figure 15-13, shows three more main categories of information.
Figure 15-13 App review and other info
There are many reasons Apple might need to contact you. They might have simple questions because you have a typo somewhere, or they might need to warn you about a violation of naming or terms. Having the right contact information and person listed can save hours, days, or even weeks when issues occur.
Using the right EULA (end user license agreement) is critical. Whether you are an independent developer or just one person in a large company, EULAs both set a base level of expectation for users and provide some protection against legal action. You can choose to use Apple’s default EULA or provide one of your own. Either way, you have to have one and make sure your app meets any conditions of the agreement. Take time to read the Apple default EULA if that is what you use.
Finally, you need to provide all the associated artwork.
The large icon used in the App Store is based on whatever you are using for the app, but it is much larger and has more detail. For CarValet, use the iTunesArtwork.png found in the CH15 Assets iTunes folder (and thanks again to Joseph Wain at Glyphish for the cool icon).
Any store listing includes one or more screenshots. These are another tool for convincing a user to choose your app. You must include at least one screenshot for each device and screen size you support. You can optionally include specific metadata and screenshots for any supported localization.
There can be up to five screenshots per device/screen size/localization, and they can make the difference between a download or not. Choose shots that illustrate your app solving problems, as well as showing how easy it is to use. Take a look at successful apps and see what they do. Some use simple screenshots, some use commented shots, and others are more innovative.
Save, Summary, and Setup
At some point, all the information is in, and it is time to commit the information. When you save it, you go to some sort of summary and management page for the new app. Figure 15-14 shows a possible screen. At this point, you can still modify most of the entered information, though not all of it. Do not be concerned if the icon is still a blank. It takes time to upload a large file, and when iTunes has it, the database has to get updated and the elves have to communicate the change.
Figure 15-14 New app almost ready
Before you return to Xcode, you need to set up the App Store to receive your app. At this writing, you do that by selecting View Details under the icon for your new app. This takes you to a detail page that might look like Figure 15-15.
Figure 15-15 Ready to upload
Let the App Store know you are ready to upload the binary, answer the question on encryption, and head back to Xcode. Whatever e-mail address you used to register your developer account is notified that the app status is “Waiting for Upload.”
Uploading to the App Store
You are almost there. The last stage is to build and submit your app to the App Store and then wait for Apple’s review and approval. Almost all this can be done with Xcode.
Building an app for ad hoc testing and for the App Store are very similar. Both require building an archive; they only differ in the kind of distribution. To build the store archive, you need five things:
A valid distribution certificate
An app ID with an App Store distribution provisioning profile
A complete App Store listing with a state of Ready to Upload Binary (see the previous section)
A correctly configured project summary and build settings for the app target
A project scheme for building a release-level archive
Note that distribution certificates are time-limited. Each certificate is valid for a period of one year, and when it runs out, you get an error saying you do not have a valid certificate. You can create a new one using the process shown earlier. Note that even if your certificate expires, any apps already out there still work as they contain a copy of both the distribution profile and the public part of the old distribution certificate.
You have already created an app ID and an App Store listing, and you have enabled Ready to Upload Binary. That leaves the project summary, build settings, and release archive scheme.
Configuring the Project
The project settings for Bundle ID and Version need to match the information in the App Store app record. Sometimes the bundle ID is set correctly because the app name is also the last part of the bundle string (for example, com.msharp.CarValet).
You use Xcode, as shown in these steps, to change the ID:
1. Open CarValet-Info.plist and look for the Bundle Identifier property.
2. Change the value to the same one in the app record—for example, com.msharp.PLCarValet. Make sure your development and distribution profiles match the new bundle string; this might require you to regenerate the profiles.
The version is set on the Summary tab for the app target. You can set both a version and a build number. You can also change the name as it appears on the iPhone. This can be very handy as you often want a different display name. Follow these steps:
1. In the Xcode Organizer, select the project.
2. Double-click the name of the target and change it to what you want. In this case, it is CarValet.
You access the settings in Xcode by selecting the project in the Navigator and then the summary for the app target, as shown in Figure 15-16.
Figure 15-16 Changing the app name
Since you have made some basic changes, now is a good time to test the app in the simulator. If you have trouble, quit both Xcode and the simulator and then start Xcode and try again. If you close CarValet in the simulator, you see two versions: one with the old bundle ID and one with the new.
The bundle ID, not the app name, is a key part of identifying your app. This is why you have to make sure the app name does not conflict with any other. Nothing in the OS prevents many apps with the same name being present on a device.
Setting Up the Project Scheme
Before you can upload your app, you need to make sure you build the right thing. A distribution version is built as an archive—a bundled-up package containing the app and some supporting information, such as the distribution profile and symbol table. Archives are also useful for backups since they represent a shipping product.
Before you generate an archive, it is a good idea to ensure that the scheme generates what you want. Usually the same scheme is used as to create ad hoc builds that are sometimes based on debugging. Follow these steps to check the scheme:
1. Use the scheme/device popup in the Xcode Toolbar to select iOS Device as the scheme target and edit the scheme. You do not need a device attached to the machine, just the device target. The target controls the kind of code Xcode builds: a device target builds ARM code, a simulator target builds an app used in the Mac simulator.
2. Edit the scheme and select Archive. You get a dialog like the one shown in Figure 15-17. Make sure Build Configuration is set to Release. (You can instead set it to Ad Hoc to generate testing builds.)
Figure 15-17 Checking the archive scheme
Tip: AdHoc and AppStore Schemes
You might have noticed a Duplicate Scheme button in Figure 15-17. You can use this button to create custom build schemes for specific purposes such as creating an AdHoc build or an App Store build. Another possible scheme can create a build for development but with debug turned off. Explore the schemes and settings to see the kinds of custom ones you can create.
Building and Uploading
The last step in submitting an app to the App Store is to create and upload the archive. You do both of these things with Xcode:
1. In Xcode, make sure the target is iOS Device and choose Product > Archive. After going through the build process, Xcode opens the Archives pane of the Organizer Window, as shown in Figure 15-18.
Figure 15-18 Archives pane: ready to ship!
2. Add a comment so you know what you are archiving. A good naming scheme will help later as you try to differentiate between individual test builds and shipping versions. The comment above is just for fun. A better one would be “Version 1.0 Build 2010.06.07.01.” A test build might be “Beta 0.7 Build 2013.06.10.07.” (See the “What Is a Build Number?” sidebar.)
3. Click the Validate button and make sure your archive is okay. Although validation is also run as part of distribution, it is better to catch and fix any errors before you do the final upload.
4. Enter your developer credentials on the next screen and then make sure the correct app and code signing identity are selected. Any problems are shown. Fix the issues.
5. Repeat the process of archiving, validating, and fixing until there are no issues.
6. To upload your app, click the Distribute button and choose Submit to the iOS App Store in the dialog. Enter your credentials, choose the app, and click Next.
Xcode uploads your app. When it is finished, you see a screen something like Figure 15-19.
Figure 15-19 Application uploaded!
You soon get a confirmation e-mail from Apple and can log into iTunes Connect to see the status. Other e-mails are sent when your app goes into review, and when it is approved or rejected. If by some chance it is rejected, you get more information on why and what you might need to do.
After you get the approval e-mail, go to iTunes Connect, view the app, and set the release date as needed. Then sit back and watch the downloads.
What Is a Build Number?
The target summary screen lets you set both a version and a build number. But what is a build number? The basic answer is whatever you want it to be. In practical terms, it is something you can use for tracking exactly when, where, and how a product is built.
Version numbers have limitations. If you are trying to ship version 1.0 of your application, the reality is you might have to go through four builds of your archive to make it work. It is all version 1.0, but it has gone through a few cycles, and any one of them could introduce something unknown.
Using build numbers is a way to set whatever meta-information you need for the particular build. The following are some possibilities:
A number incremented by one for each build
The date of the build in some format (for example, YYYY.MM.DD)
The date of the build and the number of the build that day (for example, YY.MM.DD.BB, where a BB of 02 would be the second build on that day)
The date and time of the build
A hashed value including information such as date and time as well as some other identifiers such as location of build
A number or hashed value indicating a source code repository identifier for the code used to build the app
The date with build number or source code identifier are the most common uses as they help QA and engineering isolate exactly what went into the build.
Some Things to Watch Postlaunch
When your app is in the App Store, there are still things to do. You need to do tasks like the following:
Keep an eye on and, where appropriate, respond to feedback.
Analyze the metrics and plan appropriate action.
Monitor the bug reporting you added and respond to bugs.
Keep up with marketing activities.
And, of course, plan your next great update or app.
Where to Go Next
You now have all the tools you need to design, build, and launch apps for iPhone, iPod touch, and iPad. As with any other endeavor, there is always more to learn. There are also many kinds of helpful resources, including books, websites, developer groups and conferences, and social media.
This book is just one in a series of iOS hands-on books. Your app might require you to have a deeper understanding of particular topics. Look for these other books in this series:
Learning Objective-C 2.0: A Hands-on Guide to Objective-C for Mac and iOS Developers, second edition, by Robert Clair
Learning iOS Design: A Hands-on Guide for Programmers and Designers by William Van Hecke
Learning iPad Programming: A Hands-on Guide to Building iPad Apps with iOS by Kirby Turner and Tom Harrington
Learning Core Audio: A Hands-on Guide to Audio by Chris Adamson and Kevin Avila
Learning Core Data for iOS: A Hands-on Guide to Building Core Data Applications by Tim Roadley
Learning iOS Game Programming by Michael Daley
Learning OpenGL ES for iOS: A Hands-on Guide to Modern 3D Graphics Programming by Erik M. Buck
Learning iCloud Data Management: A Hands-on Guide to Structuring Data for iOS and OS X by Jesse Feller
Other books go even deeper:
Xcode 4 Unleashed, second edition, by Frederic F. Anderson
Programming in Objective-C by Stephen G. Kochan
Effective Objective-C 2.0: 50 Specific Ways to Improve Your iOS and OS X Programs by Matt Galloway
iOS Auto Layout Demystified by Erica Sadun
Core Data for iOS: Developing Data-Driven Applications for the iPad, iPhone, and iPod touch by Tim Isted and Tom Harrington
Test-Driven iOS Development by Graham Lee
Recipe and pattern books are a great way to find solutions to coding problems or app features. They also give you ideas for new features. Try these:
The Core iOS Developer’s Cookbook by Erica Sadun
The Advanced iOS 6 Developer’s Cookbook by Erica Sadun
Cocoa Design Patterns by Erik M. Buck and Donald A. Yacktman
This is a familiar conversation:
Coder A: “Hey, how do I <do some task/make some effect happen/...>”
Coder B: “Good question; did you Google it?”
Googling a problem can help, but how do you know what links to click? And when you get to a page, how do you know if the answer is a good one?
There are many resources on the web for solving coding problems, from Q&A to blogs. All of them can help you solve a problem or at least get you started. Here are a few good ones to get you headed in the right direction:
Developer Groups and Conferences
Nothing beats face-to-face conversation, especially when the person you are talking to has already solved the same problem you’re facing. And this goes not only for coding problems, but for the other areas that make an app successful: design, marketing, business, and so on. Conferences and local developer groups are great places to network with others.
No matter where you are, there are likely others creating iOS apps somewhere near you. Local developer groups exist all over the world. Finding them can sometimes be challenging, but the web can help. In addition to doing a simple search, you can look at a couple mobile group–aggregating websites:
Apple’s Worldwide Developer Conference (WWDC) is the most valuable iOS developer event. If you cannot get there (or even if you can), you can check out the session videos. They’re well worth watching, often more than once. By only watching the videos, you miss the opportunity to talk to Apple engineers and the mass of attendees. Unfortunately, it has been very hard to get WWDC tickets in recent years; they usually sell out soon after sales start (70 seconds for WWDC 2013).
Luckily, there are many third-party developer conferences around the world. They range from fully produced events with top-tier speakers to semi-crowd-sourced hackathons. All of them can be valuable sources of learning and networking, as well as opportunities to meet vendors for metrics, testing, bug reporting, and so on.
Again, you can do a simple web search. And here are a few iOS-focused events and event aggregators to get you started:
In addition, there are a number of more general mobile conferences covering iOS as well as other platforms.
Other Social Media
You can find discussions about almost anything on social media, and iOS development is no exception. All the major services have groups, areas, and/or people. Again, you can do searches on your favorite places. And this section lists some to get you started.
LinkedIn has a number of dedicated and related discussion groups, some open and some moderated, including these:
All the subgroups of “iPhone OS Developer Network”
Cocoa and Cocoa Touch Developers
Facebook has groups, though not a lot of them are technical, and some of them are the Facebook pages for websites. Here are a couple to get started:
Twitter has many good programmers and thought leaders contributing content. Some are feeds for website content, some for blog comments, and some are pure Twitter. Check out these:
This is a good article on inspiring people for iOS developers to follow:
In this chapter, you took your app from an on-machine almost beta to waiting for review in the App Store. You started by learning about certificates and profiles and then generating your development credentials. You also learned how to generate your own certificate and profile, just in case Xcode has a problem. Next, you saw how to generate an app ID and provisioning profile and keep Xcode up to date. Then you added app icons and launch images, and learned all the different sizes.
The next step was learning about prelaunch activities. You saw several options for bug reporting, metrics, and quality assurance. Then you got an introduction to app marketing.
You moved on to creating an app listing for the App Store and learned the importance of bundle IDs, names, launch dates, app category, descriptions, and screenshots. Then you updated the app to “Ready to Upload Binary” status. With the App Store waiting, you learned how to configure the project to match the store information, change the on-device name, and check the project archive build scheme. Then you learned how to create and validate an app archive and upload it to the App Store.
Along the way, you learned about different types of quality assurance, reminding users to review and tell friends, and some things to watch after an app has launched.
Now it is time for you to design and build your own apps. As you encounter challenges, you can refer to explanations in this book. And as you get more experienced, the resources listed in this chapter can help you grow.
As you develop apps, there will be easy things and hard things, fun times and frustrating times. But through it all, remember to enjoy what you are doing.
1. Create a full set of five screenshots for each screen size for the CarValet app.
2. Sketch out a high-level marketing plan for CarValet.