同步阅读进度，多语言翻译，过滤屏幕蓝光，评论分享，更多完整功能，更好读书体验，试试 阅读 ‧ 电子书库
Chapter 12
Deploying Your iOS App
WHAT YOU WILL LEARN IN THIS CHAPTER:
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:
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 IDWhen 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 DevicesGenerating 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 CertificateCreating 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 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.
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 ProfileSigning 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 FileWhen 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 DeviceSUBMITTING 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 ConnectCreating 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 ProfileValidating 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 StoreSUMMARY
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请支持我们，让我们可以支付服务器费用。
使用微信支付打赏