No, “beta” is not the name of a fraternity of iPhone app developers. When software is labeled as “beta,” developers are communicating to customers that they may encounter problems and should use the software at their own risk. Over the past several years, the latter warning has largely become meaningless because of how long software has remained as “beta” software. For the purposes of this book, “beta” will mean the app you distribute to customers prior to it being on the App Store.
Don’t think about beta as being your opportunity to release a half-completed app. Instead, consider it a continuation of building the best product and further developing relationships with those who will eventually help you market your app. By releasing a beta app outside the App Store, you’ll continue to validate assumptions, hone product features, and find out what’s broken (yes, something will be broken). In general, you’ll be doing yourself and your customers a huge favor.
Note
It’s time for your next marketing checkup. Revisit the Phase 3 section of Chapter 8, as it will help you recruit customers for beta testing (in particular, see the Recruit beta testers section of that chapter).
To test your app with others who are not on your team, you’ll need a key ingredient besides your app: customers. At this point in the development process, you should already have a pool of customers who are willing to be beta testers. You shouldn’t be wondering who these customers are or whether they have iPod touches, iPhones, or iPads. If you don’t understand who your customers are, revisit Chapter 3 because you have bigger problems than what will be uncovered in beta testing.
Even though you should know who is interested in testing your app, there are still some basic criteria for identifying who qualifies as a beta tester. If your app takes advantage of any device-related features—for example, video—this will limit your beta testing pool. A slightly less obvious item is related to the device’s operating system. Your testers may be running older versions of iOS that could prevent them from installing your app. Although you will need to qualify testers, don’t be too limiting because you will want to have your app tested across many different device and iOS combinations, provided that they meet the minimum requirements.
Both the device and the iOS requirements are straightforward items to communicate and subsequently filter potential testers. What’s more difficult is putting the app into your testers’ hands and then incorporating their feedback into the development process. Collect their UDIDs if you haven’t done so already, and upload them into the iOS Provisioning Portal. Refer to the previous section to learn how to do that; you can use the instructions for installing the app on the device to guide your testers through the rest of the steps to install your app (see Figure 6-7). My recommendation is to have them use the iPhone Configuration Utility; it requires some additional steps, but it will make the actual installation process smoother.
Due to the high number of logistics involved in ad hoc distribution, make sure you’ve tested your app internally before you start distributing it. In fact, you and your team should be using the app extensively before customers receive it. It’s important to respect your beta testers’ time. They shouldn’t be identifying basic errors or problems with the app. You should.
Get App Savvy now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
