Almost the very first thing that you’re going to have to do when you sign up for a corporate iOS developer account is to accept the terms and conditions (T&Cs) of the App Store. Ask yourself, do you personally have authorization to enter into contracts on behalf of your company? I’m guessing the answer to that is no. So, before you really get started at all, you’re going to need to have the T&Cs reviewed by corporate counsel, and be given approval to accept the terms on the website.

This is also a dandy time to have a conversation about what will need to happen the next time the T&Cs change, which happens with distressing regularity. Pretty much whenever any new feature is added to the store (iBooks, in-app purchases, etc.) the T&Cs change. While it may be seductively tempting to just check the “I agree” button and go on with your life, it will not amuse the lawyers in the slightest.

This is not a trivial concern. Usually, you only get a window of a few weeks to agree to new T&Cs before your account gets suspended. Imagine if you get a new set three weeks before a product launch, and your legal department decided to be slow to get approval back. These are the situations that keep the American pharmaceutical industry in business.

If you’re really lucky, your legal team may come back and want to make amendments to the T&Cs before agreeing to them. I’ve never personally tried to get Apple to agree to a change in the stock T&Cs, so if this happens to you, let me know how it goes. I suspect with hundreds of thousands of developers to manage, your company isn’t going to appear as enough of a blip on Apple’s radar to get special attention.

While you’re talking to the people with Esquire after their names, it’s also a good time to discuss the EULA between you and your users. If you don’t provide one, you get Apple’s stock EULA. Almost certainly, this isn’t the EULA that you will want to ship with your product. The good news is, you have until the actual go-live of your app to get your EULA in order, but it’s best to get the ball rolling now. Also ask if the legal folks will want different EULAs in different countries, and if they want to have the EULA translated into different languages. You won’t need to actually do this work—your translation team will—but you will need to have it available to cut and paste into the app description at the appropriate time.

If you haven’t worn out your welcome by now, also find out what open source licenses are acceptable to the company, and discuss how any attribution requirements will be handled. Many applications choose to have the attributions for any open source packages they use displayed on a special tab on the Settings page for their app. There’s a great little script I found, written by a Stack Overflow user called JosephH, that will automatically generate these settings pages, I’ve included the script and the instructions on how to use it in the downloadable files for this chapter.

Your next stop should be to the marketing group, probably with your product manager in tow. There’s not a lot of flexibility in how applications appear in the iTunes store. You can’t do much formatting of the text, you get a fixed number of screen shots, and so on.

You need to communicate these limitations very clearly to your creative team, so that they can start thinking about how to best present the new app. Do they want to have an independent website that has a more glossy, polished look, with a link to the app store? Do they want to translate the app store into multiple languages (something iTunes supports)?

You should also make sure that you all agree on what the application is going to be called, and make sure that name isn’t already in use. If it isn’t, it’s probably a good idea to get it trademarked, so that you can prevent someone’s flatulence app from appearing with a similar name.

There’s a bit of a delicate dance regarding reserving names in the App Store. Once you create a new app, you have 90 days to upload a binary into the store, or you lose the name forever. It’s important to note that you don’t need to place the app up for sale, just upload a binary. As will be discussed later in the chapter, it’s a good idea to upload early and often, so this is probably not as much of an issue as it might seem, but it’s important to remember that you may have a window of time where you’ve picked a name, but haven’t reserved it yet. That’s why trademarks can be your friend.

Ready for your last stop? Find out who controls product ordering and fulfillment, and set up a meeting. Almost certainly, they have never encountered the kind of sales channel that iOS apps pass through, and it will require some adjustment on their part.

To begin with, you’re going to have to explain to them that the concept of a Gold Master isn’t going to apply to the App Store. In point of fact, there is no physical artifact that represents the version of the product you upload for sale into the App Store, because the only way to do it is from inside XCode.

This can lead to some weird circumstances. For example, you may be contractually required to ship a physical copy of the app to some customers. So what exactly is going to go on that CD? An Ad Hoc IPA file? They can’t use it, since their devices won’t be on the provisioning profile. A copy of the IPA that got uploaded to the App Store? You can only install those by downloading them directly from the Store. A README.TXT file? Believe me, you’d rather get this conversation started early, rather than be negotiating at the last moment.

Another issue to discuss is how the final production build will be created and uploaded to the store. It needs (as has been previously mentioned) to be done from XCode, which means a Mac and someone who knows how to drive it. They almost certainly do not want you uploading it from your development machine. The accommodation we came up with was to fire up XCode on the build machine (that runs Hudson), point it at the directory with the sources for the last successful build, and do an archive and upload from that.

But wait, there’s more! How will the product be priced? Will it be given away, and revenue made on server licenses? Will there be volume license arrangements available? Apple has just recently added the ability to do custom volume deals with companies, so this may be something you need to discuss with your fulfillment team. What kind of sales reports will they want out of iTunes Connect? Where do the checks from Apple need to go? Make sure that you’re all on the same page regarding the logistics of selling via iTunes.

If you haven’t run out of hours in the day yet, go talk to the User Experience and UI Design team that will be working with you. Make sure than have looked at Apple’s UX guidelines, so they are familiar with the look and feel Apple expects in their apps.

Also, you’re going to need to discuss graphic assets with them. Depending on which devices you plan to deploy on, you may need as many as four different resolutions of each image, and almost always need at least normal and 2X versions. Make sure that they know about the iOS naming conventions for the various resolutions of images, so they will name them correctly to begin with.

If you haven’t done so yet, upload a binary into iTunes Connect and start a review on it. You can have a binary reviewed without putting it up for sale, so this is a good first chance to make sure there are no problems waiting for you down the road. Of course, the app better work, not crash, etc., or it will get bounced. Frankly, if your app is still doing that stuff this close to release, it may be time to have that career-limiting conversation with your manager about slipping the ship date.

The other reason that it’s a good idea to get a build approved now is that, should something go wrong with the approval of the final build, you’ll have a backup (the build that was approved earlier) ready to go live in the app store that may not be perfect, but will do the job.

Now is the time to make sure that all the legal stuff like EULAs are in place, that you have screen capture and marketing copy for the app store entry, and that any attribution notices are either in the app itself or in the App Store description.

Depending on how you are selling the app (e.g., free with a backend license, directly sold through the App Store), you can expect to receive your bug reports from many different channels. They may show up as negative comments in the App Store. They may come in as calls to the support organization. You can get crash reports via iTunes Connect. Coordinating all this with the support organization will be complicated, and probably something they’re not used to. In some companies, bug fixing is handled by a different group than mainline engineering. If so, are there qualified engineers in the organization that can diagnose and fix bugs in iOS applications?

There may also be some institutional inertia to unstick. Companies used to quarterly or half-yearly patch releases for their server products may be unaccustomed to the idea of near-instant releasability of fixes to the customers through app updates. More than once, we had conversations that started with “but what happens if they’re running the last version of the software?” The idea that you could keep all your customers at the latest release (or require them to update their apps to fix problems) is very foreign to most enterprise companies.

Be aware that there’s a corollary problem that instant updates can bring, which will be discussed in Chapter 8.

If you’ve been automatically inserting build numbers into your version numbers, you just need to create a new version in iTunes Connect that matches that build number, and use XCode to archive and upload the app. If you’re doing it by hand, remember that the version numbers have to always increase from one version to the next, and must match between the version in the plist file and the version you create in iTunes Connect.

Once it’s uploaded, it will head off for review. Make sure that if there are test servers the Apple engineers will have to use to test the app, that they are up and any necessary credentials are included in the testing notes in the version description. Believe it or not, Apple does in fact try to use your app—it’s not just some automated servers somewhere scanning your code for bad API calls. I know from personal experience.

If you haven’t discussed the actual mechanisms of “pulling the trigger” with all the concerned parties, now is a good time. Once you release an application into the store, it can take time to propagate, especially to non-US versions of the store. If it’s critical to the timing of the launch that the app be available at a certain time, it may be worthwhile to “pull the trigger” the night before.

Also, now is the time to work out your launch-day plan of operations. Who is going to make sure that the app is in the store, and that it downloads correctly and works? Remember that until it goes live in the store, you can’t download it and check it. If it’s going up for sale in multiple versions of the store (i.e., different countries), do you have people with accounts in all those countries that can check that it went live?