The App Business Blog

Right after WWDC I wrote a short note about a new feature in iTunes Connect that allows you to request promo codes for app updates and how you could use those promo codes for testing the final app binary before it’s released on the App Store.

With the release of the new iTunes Connect UI almost everything looks different, but the same features are there. So here’s a follow up with screen images and step by step instructions.

1. Manually release the app

You should always, always release your apps manually instead of having them be released automatically as soon as they are approved. Odds are that your app will be automatically released on a Friday or Saturday evening and then your weekend may be spent answering support emails. So for your own sanity, release apps when it’s convenient for you. Manual release is also a requirement for this promo code testing trick to work.

2. Submit your app for review as usual

Nothing new or different here. If you forgot to select manual release you can still change this while the app is waiting for review.

3. Pending developer release

When the app has been approved it will be in the state Pending Developer Release. At this point the Promo Codes link appears at the bottom of the app details page.

4. Request one or more promo codes

This is the same old process you have probably used in the past to request promo codes for press contacts. Make sure you read the rules so that you do not violate the contract governing how promo codes are to be used. I’m not a lawyer, so I cannot provide advice here.

5. Download your app using one of the promo codes

Downloading an app using a promo code is usually a straightforward process. But in my experience when the promo code is for an update, iOS sometimes gets confused. It’s not consistent. But sometimes the App Store app shows an Update button right after the download is complete. It’s not clear to me if tapping the Update button will download the update you really want, or if it will “update” to the latest public release available on the App Store. Sometimes the whole process fails and my update is nowhere to be seen. So don’t be dismayed if need to burn more than one promo code to get the binary you want downloaded onto your device.

If your app saves any data you should test the upgrade scenario where you have a prior version of the app installed on the testing device. Upgrading from the App Store in this way is what your customers will experience and this is very different from when you are running and upgrading the app from Xcode.

6. Reject or release

If all testing goes well you can release the app at your convenience and in coordination with your release campaign. Tap on the Release This Version button at the top right of the app details page.

If during your testing you find any showstopper bugs you can reject this binary instead of releasing it. Click on the Cancel This Release button in the Builds section of the app details page.

Remember that Apple keeps a detailed history on all status changes of your apps. So don’t reject the binary after it has been approved by app review unless it’s really necessary. When you cancel the release you’re telling the app review team that they just spent time reviewing your app for no good reason since that version they reviewed will never see the light of day.

So don’t use this method as your early stage QA. Use it as your final, final confirmation that nothing went horribly wrong in the very last build step. Give yourself the peace of mind knowing that your customers will not face a botched binary when they go to update your app.

written by Nick

Every year at WWDC I make a point of having a meeting with the App Store team. If you are selling apps on the App Store, then nurturing personal connections with this team is one of the most profitable activities at WWDC in my opinion.

Every year as far back as I can remember I’ve asked the App Store folks if they are going to implement a way to test the final app binary before it’s released to the public. For the past two years they have hinted at an upcoming feature that will allow you to request promo codes for app updates. This year they surprised me by answering that this feature is now available.

Why is this a big deal and how is it useful to me?

Since promo codes were introduced for apps, you have been able to request and distribute promo codes as soon as an app has been approved by app review. Promo codes work even before the app is publicly available on the App Store. The business reason for this is so that you can send promo codes early to the press and have them write reviews that can be published on the day that your app goes live.

But you can also send yourself a promo code. This will allow you to do a round of final testing on the actual binary that customers will see when they download the app from the App Store.

No more crossing your fingers and hoping that the very last build and code signing you do before uploading your app to Apple didn’t introduce some odd error.

Previously promo codes were only available for new apps and not for app updates. That made the promo code testing trick less useful because you could only benefit from it once in the lifespan of your app. But now you have a way to test the final binary of all your releases.

written by Nick \\ tags: promo codes

One of the great advantages of the iPhone platform is that it’s a single target to develop for. It doesn’t suffer from the “write once, test everywhere” syndrome of J2ME. But with 2.0, 2.1 and future firmware releases, not to mention rumored tablets and other new touch products, this will change.

The other day I managed to write an application that worked on 2.0 but not 2.1 devices. After some investigation I found that the root cause was a subtle change Apple made in 2.1 without any notification in release notes or in the SDK documentation.

Consider this very common snippet of code:

NSData *webData = [NSData dataWithContentsOfURL:url];

If the url in the above example refers to a file that is gzipped, e.g. www.myserver.com/file.gz, NSData will now (in 2.1) unzip the data automagically. So if your code was expecting to receive a representation of the compressed file, it will now break.

Most browsers will to the gzip/gunzip automagically when a web server sends compressed content. This is done to save bandwidth, improve download speed, and is generally a Good Thing. When the same “feature” is implemented in the SDK and you are not given any control over the behavior, that’s a Bad Thing.

The moral of this story is that you need to test all your code on both 2.0 and 2.1 devices.
 

written by Nick \\ tags: NSData