预计阅读本页时间:-
Chapter 12
Deploying Your iOS App
WHAT YOU WILL LEARN IN THIS CHAPTER:
- Registering beta devices
- Creating and deploying ad hoc builds
- Using iTunes Connect
- Submitting to the Apple App Store
You have now created a universal iOS application. The next step is to send the app to beta testers and ultimately submit it to Apple for release in the App Store. Both of these processes are complex and highly specific to the application you are developing. They involve using Xcode and the iOS Developer portal as well as using the iTunes Connect portal, so you need to be a registered iOS developer. The iOS Developer program costs $99/year. You can enroll in the iOS Developer program by executing the following steps:
广告:个人专属 VPN,独立 IP,无限流量,多机房切换,还可以屏蔽广告和恶意软件,每月最低仅 5 美元
- Going to http://developer.apple.com/register.
- Signing in with an existing Apple ID or creating a new one.
- Selecting either an individual developer account or a company account (you can change an individual account to a company account at any time by contacting Apple and providing additional information).
- Entering all the information required and completing the purchase with a valid credit card (you must use a valid credit card to enroll. There are no other payment options).
This chapter walks you only through the steps you would follow to create beta versions of an iOS app as well as the steps you would follow to submit the app to Apple. It is based loosely on the Bands app you created in this book, but the details will be up to you when you create your own app and are ready to test and deploy. Technically, you can use this chapter to create a beta version of the Bands app, but you cannot release the Bands app you have built throughout this book to the App Store. Doing so would be stealing the intellectual property of this book as well as a violation of copyright.
Beta testing iOS applications is extremely important. Testing only in the simulator or on your own device is not enough. The simulator does not mimic all the system software and processes that are always running on an actual device. Similarly, when you run a debug version of an app on a device, it disables some of the processes the system uses to terminate apps that have gone afoul.
WARNING This is mentioned again for emphasis: Do not submit an app to be sold in the App Store without doing beta testing on actual devices.
Also many legacy devices do not have the same capabilities as more modern devices. Older devices have much less memory available. If your app uses too much memory or does not properly handle its allocation, the system will force your application to exit. Older devices also have older processors. If your application has complex animations, they may be choppy on older devices. If your application uses table views like the Bands app and does not create or reuse the cells fast enough, the scrolling will not be smooth.
It is always a good idea to see how others use your application. You may find that parts of your app that seem simple to you are difficult for others. You may also find that some users never find features or even touch gestures you think are obvious. These can lead to bad ratings and reviews, which ultimately means fewer purchases and downloads.
When you are happy with your app and have found all the bugs and usability issues, it’s time to submit it to Apple for release in the App Store. Apple reviews all apps before they are released. Even though you may think there are no other issues, your app could still be rejected. The two most common reasons for rejection are crashes and bugs, which is why beta testing is so important before submitting to Apple for approval.
If your app is rejected the first time you submit it, don’t panic. It is a common thing. Just read the rejection reasons carefully and make the appropriate changes. If you don’t understand a reason, you can contact Apple for more details. After all the issues are fixed and your app is accepted, you can smile and know you are now a published iOS app developer. Then you can start planning your next version!
DEPLOYING THE APP TO BETA TESTERS
Beta or developer preview releases of an iOS app are called ad hoc builds. The process for creating an ad hoc build is more involved for iOS apps than for other platforms you may have developed for. Any device on which you would like your ad hoc build to run must be registered with Apple to use Apple’s digital rights management system (popularly referred to as DRM). Ad hoc builds include a provisioning profile that contains all the devices on which the app is allowed to run. They are also signed with a digital certificate that must also be registered with Apple. It may sound complicated; that’s because it is. In the early versions of the iOS SDK and developer portal you needed to follow many detailed steps to get it right. As the SDK and portal have matured, there have been significant improvements to the different processes. When you get everything right a couple times, it almost becomes second nature.
Registering Beta Devices
The first step to deploying an ad hoc version of your app is to invite beta testers and ask for the Universally Unique Identifier (UUID) of their device or devices. Every iOS device has a UUID that is unique to it out of all devices ever created. When you invite beta testers, you need to tell them how they can get the UUID of their device so that you can register them with Apple and include them in your app’s ad hoc provisioning profile.
TRY IT OUT: Getting an iOS Device’s Universally Unique ID
- Open iTunes on either a Mac or a PC.
- Connect the device to the computer.
- Select the device from the iTunes menu bar.
- In the device information, click the Serial Number label to reveal the Identifier, as shown in Figure 12-1.
FIGURE 12-1
- Right-click the Identifier to copy to the pasteboard.
How It Works
iTunes is used to manage iOS devices for all users. Included in that is the ability to get the UUID of the device. Because the UUID is not something the casual user needs to see, it’s hidden until revealed using the Control-click procedure. The UUID is long and can be difficult to transcribe, so Apple added the right-click option to copy it to the pasteboard where it can be pasted into an e-mail and sent to a developer.
When you have a beta tester’s UUID, you need to register it with Apple in the iOS Dev Center. You are allowed to register only 100 devices. Though you can disable a device, you can delete them only once a year when your developer membership is renewed. With that in mind, you should be judicious in whom you invite to beta test your apps. Having a beta tester who constantly upgrades or exchanges devices may not be the best choice because the old device IDs still count against your device limit for that year. Also be wary of beta testers who never give you any feedback.
TRY IT OUT: Registering Test Devices
- Go to the iOS Dev Center in the web browser of your choice using the following URL: https://developer.apple.com/devcenter/ios/
- Sign in using your iOS Developer Program username and password.
- Click the Certificates, Identifiers & Profiles link on the right side of the page.
- On the next page, click the Devices link in the iOS Apps section, as shown in Figure 12-2.
FIGURE 12-2
- On the next page, click the + button to bring up the Registering a New Device or Multiple Devices page, as shown in Figure 12-3.
FIGURE 12-3
- Select the Register Device radio button and enter a name for the device along with the UUID. Click Continue at the bottom of the page.
- Review the information. If everything is correct, click the Submit button.
How It Works
The iOS Dev Center is where you manage all your devices and ultimately generate your provisioning profiles. Registering device IDs makes them eligible to be included in a provisioning profile. Be sure the UUID is correct. After it’s registered it counts against your device limit even if it’s incorrect. You can disable a UUID once it is registered, but it will still count against your 100 device IDs per year. When you renew your developer account after one year, you will be able to delete any disabled devices.
Generating Digital Certificates
When you build your ad hoc app, it needs to be signed with a digital certificate. Signing software with digital certificates has been around for a long time. They are used to create a chain of trust, so users know that the software they are installing was indeed created by the company or developer who created the software and that it has not been altered. When the app is signed, it creates a digital hash using the binary that can then be calculated and checked when being installed. If the hash does not match what is included in the signing information, the software is considered dangerous. It may contain malicious code added after the developer genuinely created the app.
To protect users from installing malicious software on iOS devices, all apps must be signed. The certificate information is specified in the provisioning profile and must match a certificate you have installed on your development machine. Because the provisioning profile is generated in the iOS Dev Center, you need to register there. The Mac operating system enables you to generate certificates and import them into Keychain. In the past you would need to use the Keychain Access app on your Mac to generate the certificate and then upload it to the iOS Dev Center. To make this process easier, Apple has included a feature in Xcode that can generate the certificate for you, install it on your development machine, and upload it to the iOS Dev Center.
NOTE There are two types of certificates used while developing and deploying an iOS app. The development certificate, created in Chapter 3, “Starting a New App,” is used only to run an app on a device from Xcode. A deployment certificate, discussed in this chapter, is used to deploy an app either as an ad hoc or through the App Store.
TRY IT OUT: Creating a Distribution Certificate
- From the Xcode menu select Xcode ⇒ Preferences.
- Select the Accounts tab at the top of the dialog, as shown in Figure 12-4.
FIGURE 12-4
- Enter your iOS Dev Center username and password.
- Click the Details button at the bottom of the view.
- In the next dialog your Signing Certificates are listed in the top part of the dialog, and your Provisioning Profiles are listed underneath, as shown in Figure 12-5.
FIGURE 12-5
- Click the + button under the Signing Certificates and select iOS Distribution. You see a prompt when the certificate has been created and submitted to Apple.
How It Works
When you click the Details button, Xcode logs into the iOS Dev Center and downloads your existing Certificates and Provisioning Profiles. When you click the + button and iOS Distribution option, first Xcode generates a new certificate on your development machine. It then installs the certificate in the development machine’s Keychain and then uploads it to the iOS Dev Center, making it available to your ad hoc provisioning profile.
NOTE When the certificate is generated, it should also be imported into your development machine’s Keychain. You can verify this by opening the Keychain Access app (Applications ⇒ Utilities ⇒ Keychain Access) and looking for a certificate that starts with iPhone Distribution followed by either your team name or your developer name.
Creating an App ID and Ad Hoc Provisioning Profile
The last piece of information that gets included in the provisioning profile is the App ID. There are two types of App IDs. An explicit App ID is used to identify a single app, while a wildcard App ID is used for sets of apps. An App ID is made up of two parts:
- The Apple-generated ID for your development account or development team.
- The bundle ID of the app.
The Bands app is not included in a set with other apps, so it would use an explicit App ID. The following Try It Out walks you through creating an explicit App ID you can use if you want to try and generate an ad hoc build of the Bands app.
TRY IT OUT: Registering an App ID
- In the iOS Dev Center, click the App IDs link on the left side of the Certificates, Identities & Profiles page.
- Click the + button toward the top right of the page to bring up the Register iOS App ID page, as shown in Figure 12-6.
FIGURE 12-6
- Set the Name of the new App ID.
- Select the Team ID for the App ID Prefix.
- Select the Explicit App ID radio button and set the Bundle ID using the recommended reverse-domain name style with the name of the app at the end (com.wrox.Bands, for example). Be sure to use the correct capitalization.
- Click the Continue button at the bottom of the page.
- Verify all the information is correct; then click the Submit button at the bottom of the page.
How It Works
The first part of the App ID is the team ID generated by Apple. You select it from the drop-down selection in the iOS Dev Center. The second part is the bundle ID. For the Bands app it’s the bundle ID you used when you first created the project in Chapter 3, “Creating a New App.”
The iOS Dev Center now has all the information it needs to create the ad hoc provisioning profile. You can create and manage your provisioning profiles in the iOS Dev Center. Xcode has some capabilities to manage them as well but its best to use the iOS Dev Center.
TRY IT OUT: Creating and Downloading an Ad Hoc Distribution Provisioning Profile
- In the iOS Dev Center, click the Provisioning Profiles link on the left side of the Certificates, Identities & Profiles page.
- Click the + button toward the top right of the page to bring up the Add iOS Provisioning Profile page, as shown in Figure 12-7.
FIGURE 12-7
- Select the Ad Hoc radio button toward the bottom of the page, and click Continue.
- On the Select App ID page, select the App ID you created in the previous Try It Out.
- On the Select certificates page, select the radio button next to the distribution certificate you created earlier in this chapter. Then click Continue.
- On the Select devices page, select the devices you would like to test on; then click Continue.
- On the Generate page give your new profile a name (Bands Ad Hoc, for example) and click Generate.
- On the Download page, click the Download button to download the new provisioning profile.
- With Xcode open, drag the downloaded file and drop it onto the Xcode icon in the Dock.
How It Works
There are three pieces of information in an ad hoc provisioning profile. The first step in the process is selecting which App ID should be included. Next is information about the certificate that will be used to sign the app when it’s built in Xcode. The last is the list of UUIDs of devices the app will be allowed to run on. After the provisioning profile is generated, you can download and install it in Xcode so that it’s available when you’re building your ad hoc beta release.
NOTE You can also download the new provisioning profile by going to Xcode ⇒ Preferences ⇒ Accounts ⇒ Details as you did when generating the signing certificate.
Signing and Deploying an Ad Hoc Build
With the deployment certificate installed on your development machine and the ad hoc provisioning profile added to Xcode, you are now ready to create your ad hoc build. Xcode can build a binary in debug mode that includes all the debug symbols, or in release, which strips the symbols. Stripping the symbols not only makes it much harder for someone to reverse-engineer your binary (as well as shrink the size of the binary), but it also makes crash logs unreadable.
When your app is running on a device and crashes, it creates a crash log. Crash logs can be invaluable when tracking down bugs. When you build a release binary, Xcode creates a file that maps the debug symbols to the binary. You can use this file to make crash logs readable again. Because these files are important to you as the developer, Xcode has an Archive feature that helps you not only keep track of release builds you send to beta testers, but also saves the symbols file so any crash logs you receive you can read. Archives can be managed in the Organizer window. From the Organizer you can also create and save the iPhone Application file (.ipa) that you send to your beta testers to install on their device. The .ipa file includes both the binary of your app as well as the ad hoc provisioning profile needed to successfully install the app on test devices.
TRY IT OUT: Creating an Ad Hoc .ipa File
- In Xcode select the Project from the Project Navigator.
- Select the Info tab from the top of the screen.
- In the Custom iOS Target Properties section locate the Bundle identifier key, and then set its value to the App ID you registered in the iOS Dev Center, as shown in Figure 12-8.
FIGURE 12-8
- Select the Build Settings tab from the top of the screen.
- Scroll down to the Code Signing section and locate the Provisioning Profile setting then expand it, as shown in Figure 12-9.
FIGURE 12-9
- Click the None setting next to Release, and select the ad hoc provisioning profile you created in the previous section.
- Change the scheme next to the Play button to iOS Device or any of the devices you have connected to the development machine.
- From the Xcode menu select Product ⇒ Archive.
- When the build is complete, the Organizer opens with the new archive listed, as shown in Figure 12-10.
FIGURE 12-10
- Select the new archive and click the Distribute button on the top right of the dialog.
- Select the Save for Enterprise or Ad Hoc Deployment radio button, as shown in Figure 12-11; then click Next.
FIGURE 12-11
- On the next screen, verify the Provisioning Profile is correctly set to the ad hoc profile you created in the previous section. Then click the Export button.
- Save the new Bands.ipa file to your desktop. You can now send this file to your beta testers.
How It Works
The first thing you did was set the bundle ID to match the bundle ID in the App ID you registered in the iOS Dev Center. That bundle ID is included in the provisioning profile and must match or else you cannot create the binary. You then changed the build settings, telling Xcode which provisioning profile should be used when creating a release binary. Keep in mind that the signing certificate used to generate the provisioning profile must also be installed in your development machine’s Keychain. You then create the archive. This builds the binary and signs it using the signing certificate. After the binary is built, the archive is created and is shown in the Organizer window. From there you can distribute the app by creating the actual iPhone Application (.ipa) file.
NOTE If the Archive option is disabled in the Xcode menu, be sure you have changed the scheme to be iOS Device or that of a connected device. If it is set to any of the iOS simulator settings, the Archive option will be disabled.
When you send the ad hoc .ipa file to your beta testers, you need to tell them how to install it. They will again use iTunes. The iTunes library includes all the apps a user has purchased through the App Store. Ad hoc builds will also be added to that library. When an app is in the library, it can be synced and installed on any device; though for ad hoc builds, the UUID of the device must be included in the provisioning profile. Otherwise the app will not run.
TRY IT OUT: Installing a Beta Build on a Provisioned Device
- Open iTunes.
- Double-click the .ipa file to add the app to iTunes.
- Connect the test device to the computer.
- Select the device and then select the Apps tab at the top of the screen.
- Find the ad hoc app in the Apps list, and click the Install button.
- Click the Apply button on the bottom right of the window.
- After iTunes has completed syncing the device, the app will be installed.
How It Works
The iTunes library contains all the apps the user has bought from the App Store and any ad hoc apps. Ad hoc apps are added simply by double-clicking the .ipa file. When an app is in the library, it can by synced and installed on any device managed by iTunes.
SUBMITTING THE APP TO APPLE
You now have built an iOS application, tested it not only on your own device and in the simulator but also with beta testers, and worked out all the bugs and issues. It’s now time to release it to the rest of the world through Apple’s App Store.
Creating an App Store release is similar to creating an ad hoc release. Instead of using an ad hoc provisioning profile, you will need to create and use an app store provisioning profile. App store provisioning profiles do not contain a list of UUIDs. Instead the App Store handles the DRM that allows the app to run only on devices for users who have purchased the app. But before your users can buy your app, it needs to be in the App Store. You manage your app in the App Store through iTunes Connect.
Exploring iTunes Connect
iTunes Connect is the portal everyone uses to manage their creations in iTunes and the App Store. This includes musicians and recording labels as well as books, audio books, and, of course, app developers. When you purchase your iOS Developer Membership, you have access to iTunes Connect. In the portal you can not only manage your apps but also agree to Apple’s contracts, see your sales reports, and manage your bank information so you can get paid. You will need to accept all the required contracts before you can submit. You will also need to add your banking and tax information. This chapter won’t detail those steps, but keep in mind they are required.
Before you can submit an app to the App Store for approval, it needs to be added through iTunes Connect. This is where you set the price and availability of the app as well as the description, copyright information, and screen shots users see when browsing the App Store.
TRY IT OUT: Adding an App to iTunes Connect
- Go to iTunes Connect in the web browser of your choice using the following URL: https://itunesconnect.apple.com.
- Sign in using your developer program username and password.
- On the landing page, click the Manager Your Apps link, as shown in Figure 12-12.
FIGURE 12-12
- On the Manage Your Apps page, click the Add New App button on the top left to start the process.
- In the App Information page, as shown in Figure 12-13, enter the name of the app, assign it a SKU number of your choosing, and select the appropriate Bundle ID.
FIGURE 12-13
- On the next page shown in Figure 12-14, select when you want the app to become available as well as the pricing information.
FIGURE 12-14
- On the next page, as shown in Figure 12-15, you need to fill out all the fields that are not labeled as Optional and click Save. You are required to upload a Large App Icon that is 1024×1024 in size as well as at least one screen shot for all devices the app supports.
FIGURE 12-15
- Your app is now in the Prepare for Upload stage. Click the View Details button.
- On the details page, click the Ready to Upload Binary button.
- On the Cryptography page make the appropriate selection referring to cryptography in the app, and click the Save button. You can now upload your binary after it’s created.
How It Works
You manage your apps in the App Store through iTunes Connect. When you are ready to submit a new app, or when you are ready to submit an update, you log in to iTunes Connect and set not only all the information Apple needs to display your app in the App Store, but also information reviewers may need to approve your app for sale.
Creating an App Store Provisioning Profile
Similar to the ad hoc build, your App Store build needs a special provisioning profile. Creating it is practically the same process as well. The only difference is you don’t need to select which devices will be allowed to run the app.
TRY IT OUT: Creating and Downloading an App Store Provisioning Profile
- In the iOS Dev Center, click the Provisioning Profiles link on the left side of the Certificates, Identities & Profiles page. Then click the + button toward the top right of the page.
- Select the App Store radio button, and click Continue.
- On the Select App ID page, select the appropriate App ID, and click Continue.
- On the Select certificates page, select the radio button next to the iOS Distribution certificate you created and used with the ad hoc provisioning profile earlier in this chapter, and click Continue.
- On the Generate page, name the profile appropriately, and click Generate.
- After the certificate is generated, click the download button and add the new Provisioning Profile to Xcode as you did with the ad hoc profile.
How It Works
This process is almost identical to creating the ad hoc provisioning profile. The only difference is the step where you select the devices on which the app is allowed to run.
Validating and Submitting an App
The final step to getting your app into the App Store is to submit it to Apple for review. The review process ensures that all apps for sale in the App Store meet Apple’s standards. There are many reasons your app can be rejected. The most common are crashes and bugs. This is why the beta testing process is so important. To help you understand the other reasons your app could be rejected, Apple provides a detailed review guidelines document located at https://developer.apple.com/appstore/resources/approval/guidelines.html. You should familiarize yourself with this document prior to submitting an app for approval.
Having an app rejected can be frustrating. The review process can take up to two weeks to complete, so getting rejected and having to resubmit can delay the release of your app considerably. To help both developers and reviewers, Apple first runs a series of checks to make sure your app meets the minimum requirements for submission. These checks are made as soon as your binary is uploaded; however, you can run the same checks from the Xcode organizer using the Validate feature. The list of checks that are performed is not documented, but common mistakes such as using the wrong provisioning profile or signing certificate will be caught by these checks. It is worth your time to run the validate feature in Xcode prior to uploading your binary to catch those issues quickly.
Creating your App Store build is exactly the same as building the ad hoc build. Because the App Store is a release binary, it will also have the debug symbols stripped, so keeping the archive is important to read any crash logs. You can then use the Organizer to upload the binary to Apple for review.
TRY IT OUT: Building and Submitting to the App Store
- In Xcode, select the Project from the Project Navigator.
- Select the Build Settings tab from the top of the screen.
- Change the Provisioning Profile for Release to the App Store Provisioning Profile you created.
- From the Xcode menu select Product ⇒ Archive.
- When the app is done building and the Organizer window displays, click the Validate button.
- Enter your developer program username and password in the dialog, and click Next.
- On the next screen verify or select the appropriate app as well as the appropriate App Store Provisioning Profile. Then click Validate.
- If any issues were found, fix them and repeat steps 1 through 7 until there are no issues found.
- From the Organizer window, click the Distribute button.
- In the dialog, select the Submit to the iOS App Store option, and click Next.
- Enter your developer program username and password in the dialog, and click Next.
- On the final screen, verify or select the appropriate app as well as the appropriate App Store Provisioning Profile; then click Submit. If no issues are found, your binary will be uploaded, processed, and queued for review.
How It Works
Before you create your App Store build, you need to change the provisioning profile used to sign the app. After you do that, follow the same steps to archive the build as you did with the ad hoc build. You can then validate the app to make sure everything is correct. When it is, you can submit the app to Apple for review. It should be noted that simply getting the app uploaded does not mean it will be queued for review. There is some additional processing that happens after the app is uploaded. If there are any issues, you will receive an e-mail telling you what needs to be fixed. If the review process finds any issues, you will also receive an e-mail with issues that need to be fixed. After the app has passed all reviews, it will be added to the App Store and ready for sale.
SUMMARY
Creating an iOS application is great, but getting it into the hands of your users is the ultimate goal. Before you start selling your app, you need to make sure you have fixed all the bugs and usability issues. To beta test your app, you need to gather your beta testers’ device IDs and register them with Apple. From there you can create an ad hoc build and have your beta testers install it on their devices and send you feedback. When you are ready, you submit your app to Apple for its final review. If all goes well, your app will be approved and ready for sale in the App Store!
EXERCISES
- What is the common name for beta or developer preview builds?
- What is the difference between a debug build and a release build?
- What are the three pieces of information you need to add to the iOS Dev Center to create a provisioning profile for your beta build?
- What is the name of the portal used to manage your apps in the App Store?
WHAT YOU LEARNED IN THIS CHAPTER
TOPIC KEY CONCEPTS
Creating Ad Hoc Builds Creating an ad hoc build when your app is ready for beta testers
Using iTunes Connect Developers, musicians, and authors managing the things they sell in iTunes and the App Store through the iTunes Connect Portal
Submitting an App for App Store Approval Apple must approve all apps in the App Store. Before your app is available for sale, it must be submitted and reviewed.