Chapter 6. Making Your App Better Before It Reaches the App Store

To further verify that your app resonates with your customers and to reduce software issues in your app, you are going to want to install it onto your device and your customers’ devices before Apple even sees it.

In this chapter, you’ll explore:

  • Installing the app on your device

  • Understanding “beta” and working with your beta testers

  • Performing quality assurance by collecting feedback

  • Working with your developer to resolve bugs

Installing Your App

Testing your app before it reaches the App Store will likely be one of the most difficult and frustrating tasks you’ll encounter. It will also be one of the most important things you’ll do.

The difficulty of this process is that Apple wants your app in its store and not “in the wild.” So, although Apple provides a means for distributing your app directly to customers, it’s tedious and limiting. The tedious part is that you need to grab some unique information from each customer’s device, called a UDID (unique device identifier); the limiting part is that Apple only provides 100 testing slots per year in the standard developer program (which is probably what you initially signed up for during registration).


Although registering for the iOS Developer Program is covered in the Appendix, it is worth noting here that Apple also has an iOS Developer Enterprise Program, which costs $299 instead of $99. Though you will still need to register for the standard program to distribute applications on the App Store, the enterprise program streamlines internal distribution and allows unlimited slots to test applications in-house. To qualify for this program, you need to verify to Apple that your company has at least 500 employees. More information is available at

To have your app installed onto your and your customers’ devices, you’ll collect UDIDs, register them with Apple, subsequently download a mobile provisioning file, and then use that file along with your app to get it working on the device. This process probably appears confusing, so I’ll walk you through each step.


“UDID” stands for “unique device identifier.” A UDID is a 40-character alphanumeric identification number that’s unique to every single iPhone, iPad, and iPod touch. You and your testers need the UDID of each device onto which you plan to install your app for testing.

UDID apps on the App Store
Figure 6-1. UDID apps on the App Store

There are several ways to collect the UDID, and I’ll cover two now. The simplest method is to use one of the dozens of apps on the App Store that will both pull the UDID from the device and quickly send it to you via email. Simply search for UDID in the App Store. The apps that appear at the top of the resultant list are your best options (see Figure 6-1). Some apps, such as Info – UDID, provide other device information, including OS version and device features.

Another method for obtaining the UDID is through iTunes. Plug in your device, select it in iTunes, and visit the Summary tab. Click the words “Serial Number” in the top section (they won’t appear clickable), and they will transform to “Identifier (UDID).” Select Edit from the menu and choose Copy (see Figure 6-2). The UDID will then be placed on the clipboard.

UDID in iTunes
Figure 6-2. UDID in iTunes

Registering a Device with the Provisioning Portal


Before you read this section, keep in mind that I won’t be dissecting Apple’s iOS Provisioning Portal (, which is part of the iOS Dev Center ( The reasons are to protect you from being overwhelmed and to continue to equip you with only what you need to know to get your job done.

This section assumes that your developer has set up your App ID and iOS Distribution Certificate, and that you have the appropriate permissions to register devices into the iOS Provisioning Portal (

You may deem what I’m about to detail for you as too technical. The truth is, you really never have to visit the iOS Provisioning Portal and can pass this task to your developer. But if you want to free yourself from always relying on your developer and help keep him focused on more important and less logistical tasks, keep reading.

The iOS Provisioning Portal is a critical part of the iOS Dev Center that provides you the resources to distribute your application both outside and on the App Store. You are currently in the “outside” state, which Apple calls ad hoc distribution, and to use this method of distribution you need to register the UDID of any devices that will run the current version of your app.

Once you have those UDIDs, browse to the iOS Provisioning Portal and visit the Manage tab of the Devices section ( This area is where you’ll be submitting the UDIDs to Apple. You can add each UDID individually or upload them all in a .txt or .deviceids file via the Add Devices or Upload Devices button. Each UDID must be accompanied by a Device Name, which helps you distinguish the UDIDs from each other. More significantly, the Device Name will replace the use of the UDID (which is a long alphanumeric string) and become the main way to reference a device. For these reasons, make this name descriptive (such as “First-name Last-initial Device-type”). For example, aside from my iPhone 4, I have a 3G and 3GS iPhone, second-generation iPod touch, and 3G iPad. So, I’d name them “Ken Y iPhone 3G,” “Ken Y iPhone 3GS,” “Ken Y iPod touch 2nd Gen,” and “Ken Y 3G iPad,” respectively.

Be careful and somewhat selective with the UDIDs that are added. Even if you remove one of the devices and then add it back later, it will still count toward the 100-devices-per-year regulation that Apple stipulates. Apple does this so that you don’t try to use this method as a permanent alternative to the App Store.

Once you add one or more UDIDs, you’ll see them added as registered devices. Notice that they will show as “0” in the Profiles column (see Figure 6-3). That will change once you complete the next step.

The Devices section in the iOS Provisioning Portal; notice the Profiles column shows 0
Figure 6-3. The Devices section in the iOS Provisioning Portal; notice the Profiles column shows 0

Mobile Provisioning File

To install an app outside the App Store through ad hoc distribution, Apple requires that a provisioning profile be present on the device. There’s more to a provisioning profile than what I’ll discuss here, but for now just note that it essentially informs a device that an app not approved by Apple can be installed.

Click down to the Provisioning section of the iOS Provisioning Portal and select the Distribution tab to associate the devices added in the previous section to the provisioning profile for your app. Although this step depends on how your developer set up the provisioning profile, it will probably be specific to your app and the type of distribution you’ll be doing. Although there are compelling reasons to have one profile per distribution type (including requiring that you and your testers install only one provisioning file for all your apps), you’ll probably want to have a quick chat with your developer if you see a generic provisioning profile name that doesn’t inform you of its contents (e.g., “mobile provision” versus “App Name Ad Hoc”).

To associate device names with the appropriate provisioning profile, click the Edit link in the last column. You’ll then be brought to the Modify iOS Distribution Provisioning Profile page, where you’ll see the distribution method of the profile, along with some other developer-centric information such as the App ID. Since the distribution method in this case is Ad Hoc, the bottom section is where you’ll be able to select the devices you want to run your app. Choose Select All if you’re adding all the device names, or use the checkboxes to select a subset of them (see Figure 6-4).

The Modify iPhone Distribution Provisioning Profile page
Figure 6-4. The Modify iPhone Distribution Provisioning Profile page

The madness is almost done. Click the Submit button when you’ve added all the appropriate devices. You’ll find yourself back on the Distribution Provisioning Profile page, with the Status of the provisioning profile (the one you just added devices to) changed to Pending. Refresh the page and it will soon read Active again. Click the Download button to finally receive your prized mobile provisioning file (which will be named according to the provisioning profile and will end with .mobileprovision). Put this file in a safe place. You and your customers will use the provisioning profile, along with your actual app, to install the app onto your device.


Anytime you add a new device for testing, you’ll need to add it to the provisioning profile and subsequently download this file again.

Development App

Up to now, you’ve likely only seen your app run in the iPhone Simulator. With all the work you’ve just done, you are close to finally seeing it on your device.

The last ingredient you need in order to install your app is the “ad hoc distribution” development version of it. Your developer should provide this file to you, which will end with .app or .ipa. If your developer doesn’t name the file descriptively enough, you may want to add the version number or date to it (e.g., “”). As you continue the testing process, you might need to revert to one particular version, and a standard naming convention will help you locate the right one.

Installing through iTunes

Take both the mobile provisioning and app files and drag them into iTunes under the Library area. You don’t need to drag them into any particular category; iTunes will know what to do with them. Connect your device, select it, and then go to the Applications tab. You should see your application available under Sync Applications. Select it and then click the Sync button.

In theory, the development version of your app should now be installed. From my experience, however, installing an ad hoc app through iTunes almost never works properly the first time a sync occurs, even if everything was done correctly.

“Signer not valid,” the most common error for ad hoc distribution installations
Figure 6-5. “Signer not valid,” the most common error for ad hoc distribution installations

The most common error for the app not being installed relates to a “signer not valid” error (see Figure 6-5). This message usually occurs when the developer’s credentials were not configured properly in building the app for distribution. Try syncing again first. If the same message reappears, your developer will need to send you a new mobile provision, new app, or new versions of both files.

During development, it’s a good practice for you to completely remove the app from your device before installing the next version of it. So, if you tested one part of the app’s functionality and then a new feature is completed and available to test, delete the app from your device and remove the existing app in iTunes (go to the Applications section under the Library area, find the app, right-click it, and select Delete; then select Move to Trash when prompted). A good practice—although definitely playing it safe—is to sync your device at that point to make sure both the device and iTunes agree that the app is gone. You should then drag the latest version of the app back into the Library and follow the aforementioned steps to install it.


Although not as conservative or thorough, you may also just want to ask your developer to update the build number, which should prompt the ad hoc app to “upgrade,” rather than following the process described in this section.

Installing through the iPhone Configuration Utility

You’ll quickly find that using iTunes to manage your app is slow and frustrating. One of my favorite tools, which speeds up the installation considerably, is the iPhone Configuration Utility (, shown in Figure 6-6). This tool does not require syncing and will allow you to install the profile and the app directly onto your device.

Drop the provisioning profile and application under the Library area. Then, attach and select your device and install the appropriate provisioning profile in the Provisioning Profiles tab. Once those steps are completed, you can install the app under the Applications tab.

iPhone Configuration Utility
Figure 6-6. iPhone Configuration Utility

More generally, as you become comfortable with this process, you may not want to wait for your developer to send you versions of your app to test. If you are willing to get more into the technical details, have your developer set you up so that you can build your app directly onto your device through Xcode. This setup will allow you to access the latest version of your app without your developer’s assistance. You’ll start by accessing your app’s repository, as described in Chapter 5. If you’d like to learn more, check out Building onto a device in this book’s Appendix.

Going Beta

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.


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).

Cultivating Beta Testers

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.

Release notes and installation instructions email for the Tweeb beta testers
Figure 6-7. Release notes and installation instructions email for the Tweeb beta testers

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.

Quality Assurance and Feedback

With some amount of patience, you should now have a development version of your app that is installed on your device and the devices of your beta testers. Installing the app was not an end unto itself, but rather the beginning of testing, refining, and improving the app.

Make Testing “Real”

Depending on the size of your team and the resources you have available, you might have one or more persons dedicated to performing quality assurance (QA). Regardless of whether that is the case (and it probably won’t be for many of you reading this book), I want to challenge you to really own the responsibility of having the right features that work properly. This means you should be the most ardent beta tester of your app, discovering obvious bugs before others do and influencing how best to improve features from your actual use of it. That’s the same way your beta testers should be experiencing the app—in conditions that reflect the real-world environment of your App Store customers.

I’m emphasizing this point so strongly because you won’t discover issues by just seeing the app in the iPhone Simulator or through formal QA by testing the app through a series of predefined steps. What makes developing for the iOS unique is that hardware heavily influences the testing process. In addition, aside from device-related features and iOS versions, these devices also have various states for network connectivity. For instance, it’s possible to have no cellular network, an EDGE or 3G connection, or WiFi present at various signal strengths. You should test, for example, the process of opening your app in Airplane Mode—available in your device’s Settings app—where no network connectivity is present and see if it works.

Many apps crash because these types of scenarios are not initially accounted for during development. To precisely state the larger takeaway, everyday conditions are hard to simulate in a formal QA process (which you should still use) and often will only be encountered by using the app outside of a testing environment. Even Apple tests its devices and apps this way, requiring its engineers to experience them in regular use outside of the Apple campus.

Feedback and Bugs

Through whatever channels you are using, keep the lines of communication open with your beta testers. When you provide them the latest development version of your app, be sure they know if you want them to test anything specific, and let them know of any changes that have been made since the last time they tested the app by including a changelog or release notes outlining what is new, updated, fixed, or outstanding. Also, remind them how to properly install the new app (refer back to Figure 6-7).


You may want to take advantage of the open source framework known as Hockey, which allows you to update your beta app remotely. Using it will remove the need to send out the latest development version. Instead, the beta app will update automatically, when a new version is available. See and for more details. Note that you should rely on Hockey for updating the app only. You still should stay in touch with your beta testers and distribute release notes and related materials.

Here is the information I included in the release notes for Tweeb:

Tweeb Release Notes

For this version of the app, please check out the new retweet features located in the “Buzz” tab. The following are the items that have changed since the last version you tested:


  • Special characters in passwords

  • Issues with counters showing “0’s” when device uses non-U.S. region format

  • Summary screen counter not showing lost/gained followers


  • Better performance when multiple accounts loaded

Be aggressive about getting feedback from your beta testers. If possible, meet with your testers and watch them use the app. Request to record their usage of the app, ask them questions, listen, and absorb as much as possible. Although you want to find bugs throughout this process, it’s more important to understand how your customers are using your app.

You should provide guidance regarding what you need from your testers when they submit bugs. A statement that reads “It crashed when I pressed a button” won’t help you much. When customers send you bugs via email during testing, they should include what device and OS they have, what type of network connection was present, what tab or screen they were on, and what specific steps caused the issue. If applicable, also ask for a screenshot.


As mentioned before, Apple made it very easy to take screenshots on its devices. To do so, simply press the Home and Power buttons at the same time. You’ll hear a camera shutter sound and the screenshot will be placed into the device’s Camera Roll.

Going Deeper with Nasty Bugs

Sometimes your developer won’t be able to reproduce a bug found by you or one of your beta testers. Thankfully, there are a couple of Apple and third-party tools that can help with this situation by retrieving crash logs and other diagnostics data to help resolve these types of bugs.

iPhone Backup Extractor

An extremely handy piece of software that your beta testers can use is a third-party tool called the iPhone/iPod touch Backup Extractor (found at the uniquely named domain

iPhone Backup Extractor
Figure 6-8. iPhone Backup Extractor

This app runs only on the Mac, but it is one of the easiest tools to use to get all the relevant files to your developer. The iPhone Backup Extractor (see Figure 6-8) will interact with your tester’s device backup files. If your tester uses it, she’ll need to first sync her device so that the appropriate files will be present in the backup.


Apple’s Xcode, which is bundled with the iOS SDK (see the Tools section in this book’s Appendix), has a tool that you will come to not only appreciate, but also use regularly: Organizer. As an aside, Organizer is another place you can grab the UDID for your device.

Once Xcode is open, you can access Organizer via the Window✓Organizer menu item. Connect your device and you’ll see it appear in the Devices area of Organizer. In the main screen, click the Use for Development button (see Figure 6-9) and you’ll see the indicator change from gray to yellow to green, and two new tabs will appear, one of which is the Device Logs tab.

Clicking the Use for Development button in Organizer to access additional features
Figure 6-9. Clicking the Use for Development button in Organizer to access additional features

The Device Logs tab (see Figure 6-10) will allow you to search for your app and then pull some critical diagnostics data for your developer to use. Most of these logs will be listed as “Crash” in the Type column. You can drag and drop any of these files, which will end in .crash, from Organizer to your computer, but look for the latest based on the Date/Time column.


Another file type—a .plist file—can be useful to your developer. A majority of the time the information in the crash log will suffice to identify and resolve the issue. The next section explains where to find a .plist file.

Another time-saving function of Organizer is the ability to take screenshots that you can immediately drag to your computer. An annoyance with using your device to accomplish this task is that email, iTunes sync, or an app is required to transfer the screenshots. With Organizer, visit the Screenshots tab, have the screen you want captured open on your device, click the Capture button, and then drag the screenshot to your computer.

Organizer’s crash logs
Figure 6-10. Organizer’s crash logs

Finding crash logs on your computer

A device’s diagnostics data (.crash and .plist files) can also be directly accessed from a computer. The prerequisite to accessing it, or at least to having the latest data, is to sync the device with iTunes.

Here are the locations where you can access these files on several operating systems. Once you navigate to the location, look for the filenames that resemble your app name.


~/Library/Logs/CrashReporter/MobileDevice/<device name>

Windows Vista/Windows 7

C:\Users\<Windows username>\AppData\Roaming\Apple computer\Logs\CrashReporter\MobileDevice\<device name>

Windows XP

C:\Documents and Settings\<Windows username>\Application Data\Apple computer\Logs\CrashReporter\MobileDevice\<device name>

Funneling Feedback

Use whatever tools you implemented in Chapter 5 to track all of the feedback, bugs, screenshots, and diagnostics files collected during your beta testing. Input, prioritize, track, and resolve both feedback and bugs. If your tool provides for it, give your beta testers direct access to log their feedback and bugs and then prioritize those items internally in order of importance.


Hog Bay Software: Jesse Grosjean

image with no caption

Company: Hog Bay Software

Position: Founder

Background: Jesse Grosjean is the one-man show behind Bangor, Maine–based Hog Bay Software. His software includes the popular distraction-free writing tool WriteRoom and the simple “paper-like” to-do list application TaskPaper, both of which exist on the Mac and iPhone.


Ken: What’s the most important step when designing a new application?

Jesse: I always start each product idea with a positioning statement following Geoffrey A. Moore’s format:

For [target end user] who wants/needs [compelling reason to buy]. [Product name] is a [product category] that provides [key benefit]. Unlike [main competitor], [Product name] [key differentiation].

This sets a foundation for the app that I use throughout the development process, and it provides the basis for marketing the app after release. Here are the positioning statements for TaskPaper and WriteRoom as examples:

TaskPaper: For Mac & iPhone users to make lists and stay organized. TaskPaper is a simple to-do list that’s surprisingly adept. Unlike standard organizers, TaskPaper gets out of your way so that you can get things done.

WriteRoom: For Mac & iPhone users to write without distractions. WriteRoom is a full-screen writing environment. Unlike the cluttered word processors you’re used to, WriteRoom lets you focus on writing.

Ken: You now have an active community of people willing to test your software and apps, but “back in the early days” when that wasn’t the case, how did you go about getting customer feedback? How would you suggest developers do that when dealing with iPhone apps and Apple’s App Store?

Jesse: Make sure that you start with an interesting idea that you can describe (positioning statement). Once you have that, then it shouldn’t be hard to get feedback. You don’t need lots of users, just three or four different conversations going on about the app as you build it. A good positioning statement is important at this stage so that you stay focused on the goal for 1.0 instead of just adding feature upon feature suggested by your early testers.

Ken: What guidance do you provide your customers when they test beta software? Do you script them in any way about what they should be testing or just let them have at it?

Jesse: I just let them have at it. Generally, I include a few notes of changes to look for in each new beta, but that’s about it. I do it this way because I don’t think that I personally would be organized enough, or have enough time, to create and maintain any more structure in the testing process.

Ken: How do you interact with your testers and community? Are there tools you use to manage those interactions? Do you use different tools internally for yourself versus externally for testers?

Jesse: Conversations can happen in my user forums, blog comments, or email. Recently (for iPhone beta testing) I’ve tried to stick more to email with all testers Bcc’d.

Ken: When dealing with bugs in particular, what do you request your testers provide you in order to more quickly resolve them? What types of bugs do your testers usually find that you miss in your own QA?

Jesse: Bugs need a reproducible case. I’ll look for bugs that are not reproducible, but that’s almost always a losing battle. In general, testers find bugs of all sorts, but for me I think a more useful part of the beta process is the feedback that I get about how the application actually works. Most of the conversation is about features to add/remove/change as opposed to bugs to fix.

Ken: Once you have feedback from your customers, how do you determine what features get added, removed, or changed in the first version of the App Store release? In particular with the gated App Store approval process, how do you determine what goes into the first release versus an update?

Jesse: I think a good rule of thumb is to release 1.0 as soon as the app’s functionality fulfills the app’s positioning statement. For subsequent updates, I just release when it seems right...balancing the desire to implement everything on my to-do list with the desire to get the release out as soon as possible. Generally, my release pattern is to do a big release with lots of changes, followed by a number of quick releases that fix bugs or polish behavior. Then not much [is released] until the next big release.

Mariner Software: Michael Wray

image with no caption

Company: Mariner Software

Position: President

Background: Michael Wray began his career in the Macintosh software industry by co-founding Power On Software in the early 1990s. In 2002, he took over the helm of Mariner Software. More recently, he brought Mariner into the iPhone and, ultimately, the iPad markets with offerings on the App Store.


Ken: You now have an active community of people willing to test your software and apps, but “back in the early days” when that wasn’t the case, how did you go about getting customer feedback? How would you suggest developers do that when dealing with iPhone apps and Apple’s App Store?

Michael: Name any era in Macintosh computing and one thing remains consistent: Mac users love to volunteer to test software. In our case, whether it was early on in System 7 days, the release of Mac OS X, to today, with the iPhone and iPad generation, Apple die-hards are eager to test new technology. Many users reached out to us years ago and have remained faithful testers even today.

Here at Mariner we make it real easy to apply to be a tester: we put a blurb on our home page on our website, post a notification in our forum, and send out newsletters reminding users they can “steer the Mariner ship” by participation in testing new products. With iPhone testing, as odd as it sounds, we literally have to be picky on who we can accept as a volunteer tester. Since Apple limits the amount of participants in ad hoc testing, we need to make sure whoever is participating is actually serious about testing.

Ken: What guidance do you provide your customers when they test beta software? Do you script them in any way about what they should be testing or just let them have at it?

Michael: When an app is in the early stage of testing, we try to set the expectations for the user. We are fortunate to have hundreds of testers to choose from that have strong beta testing experience, and thus, know what to expect. Obviously the words “PLEASE MAKE SURE YOU HAVE A BACKUP SYSTEM IN PLACE” are littered all over the documentation. The last thing we want is to be responsible for losing a user’s data (fortunately, it hasn’t happened to us). In terms of a script or path for users to follow, we rarely give them that direction. Having users use our software in their own environments and workflow is incredibly crucial for us. We have a pretty good testing lab, but there’s no way we would ever be able to duplicate what users see on an everyday basis.

Ken: How do you interact with your testers and community? Are there tools you use to manage those interactions? Do you use different tools internally for yourself than the ones you use externally for testers?

Michael: We have a private (password-protected) forum where we communicate with our testers (and they with us and other testers). We have also implemented a support/knowledge base solution called Tender that is really helping with communication.

Ken: When dealing with bugs in particular, what do you request your testers provide you in order to more quickly resolve them? What types of bugs do your testers usually find that you miss in your own QA?

Michael: We encourage them to provide us with a bug report, so we can see exactly what was happening at the time of a crash. Providing in-depth background info for our QA folks is so critical to reproducing a problem. When we need to go back and forth with a few emails to get that information, the solution is usually delayed. Our testers usually find oddball bugs that happen in small quantities. That being said, there have been occasions where we missed something that I’m sure our users were scratching their heads over.

Ken: Once you have feedback from your customers, how do you determine what features get added, removed, or changed in the first version of the App Store release? In particular with the gated App Store approval process, how do you determine what goes into the first release and what goes into an update?

Michael: For every first-version app in the App Store, we have been able to draw from a close group of power users (as well as internally). Honestly, a lot of it comes down to supply and demand. If we get enough “demand” for a feature from several power users we poll (and it doesn’t take a year to implement!), we usually “supply” it. In terms of what makes the cut in version 1.0 of an app, many times it’s bandwidth-driven. If at that time, we have development bandwidth available, we usually can add more features in version 1.0. If our development team is juggling several different products and they are under major deadlines, the reality is that sometimes features will slip to a later release. It’s not ideal, but we do the best we can with the resources we have.


Here’s what you learned in this chapter:

  • The process of installing an app outside the App Store requires your and your testers’ UDIDs. You discovered several different ways for pulling the UDID off a device.

  • Although you may decide you want your developer to handle the iOS Provisioning Portal, you became familiar with the aspects relevant to you and can add new testing devices to your ad hoc development mobile provisioning file.

  • Cultivating a group of beta testers is going to vastly improve your app before it hits the App Store. You should be the best beta tester and constantly use the app in “real-world” conditions.

  • Using Apple’s Organizer, using other available tools, and being familiar with the diagnostic logs will get you, and ultimately, your developer, the information needed to troubleshoot and resolve the major bugs in your app.

  • All of the feedback and bugs discovered through your testing process should be funneled into one location where you can prioritize, assign, and track them.

Get App Savvy now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.