One of the most confusing parts of iPhone development is dealing with the iPhone Developer Program side of things. You know, all that fun stuff with certificates, devices, provisioning profiles, distribution profiles, etc. Oh, the hours of “fun” you can spend with that.
Last night was particularly frustrating because I had just called it “beta” on Flower Garden and celebrated with the requisite victory dance, when the fun of sending out the beta build started. What I thought would be a ten-minute task, turned into a long nightmare and I didn’t get the build out until 1AM.
This is not the first time I run into issues with provisioning profiles and distribution in general. It’s a very finicky process, and other developers are going through the same pains. Mark Johnson suggested I collected all the gotchas I’ve learned into a single place so it can serve as a form of reference. That’s a great idea, because the process is so byzantine that I will have forgotten most of them next time I need to do another big submission.
This is not a “how to” document on preparing your builds for ad-hoc or App Store distribution. Apple has the basic flow documented in their site, and other people have also talked about the process. This is intended to be more of an appendix explaining details, clarifying assumptions, and correcting things that are just plain wrong.
To make this more comprehensive, I’d like to open it up to other people’s experiences, not just mine. If you have gone through some pains with the iPhone Developer Program (and who hasn’t?) and found a way to deal with them, please post in the comments and I’ll update this page to reflect it.
iPhone Developer Program
1. App identifier is case sensitive. This is the string you need to enter when you create an app ID through the developer web site, and the one you need to set in your Info.plist. My usual development id is com.snappytouch.* so I can use it for anything I do. But in preparation for sending out the beta build, I created one just for Flower Garden: com.snappytouch.flowergarden. I thought that everything on the build side of things would be fine because my default app ID was: com.snappytouch.${PRODUCT_NAME:identifier}. Unfortunately, this failed to create a working build without any helpful errors. After much hair-pulling, I figured that was because my app is called “FlowerGarden” not “flowergarden”. Changing the app ID in XCode to com.snappytouch.flowergarden fixed that.
2. Easy UDIDs. Forget about asking your testers to go to iTunes and get the UDID from there. Instead, tell them to get BetaHelper and email you all the information directly. Easy and no typing errors!
3. Bulk device upload. I got a great response to the call for beta testers for Flower Garden, so I was left with about 30 new device UDIDs to enter in the developer web site. Entering them one at a time with a slow-as-molasses interface isn’t my idea of fun so I decided to use the bulk upload option. Unfortunately the format isn’t described exactly anywhere, and the errors displayed if the format doesn’t match exactly are meaningless.
The exact format is:
Device ID Device Name xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Whatever name here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Lalalala xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Whatever
So, tab separated, not comma separated. First column is the device ID (40 digits). Second is the name, no quotes around it. First line is ignored. Here’s the killer: You cannot have any blank lines after the last entry. And the error message if you do is simply a “Bad format”. Come on Apple, throw us a bone over here! One last thing: You can’t upload a device ID that is already in your database. Really annoying. Still, beats cut and pasting all those IDs by hand.
4. Ad-hoc zip file for Windows users. Apparently it can’t be created with the Compress option in finder because it puts extra files. I used zip from the command line and it worked correctly. (Thanks to Mark Johnson for that one).
5. App Store zip file has to be created through Finder with Compress. I heard that on Twitter somewhere, but needs confirmation. Anyone?
6. Adding provisioning profiles. Forget about dragging them on XCode and manage them manually. Check out my earlier entry about it.
7. Set correct provisioning profile everywhere. And I mean everywhere. You need to do it both in the Info for the target and the info for the project itself. Yes, both dialog boxes look identical and have 99% the same information, but the provisioning profile setting is different apparently. Fail to set it in both places, and your app won’t load in the device.
I’m sure there are a lot more. If you’ve found some of your own, leave a comment and I’ll update the list.
Regarding number 5, I use this command to zip my apps for the app store:
ditto -c -k -X –keepParent AppName.app/ AppName.app.zip
I cant tell you exactly why that works, but I know it does! Ditto is apparently some OSX super command that plays nice with resource forks, and copies or zips files.
I feel more comfortable when my production builds come from the build system, rather then by manual process.
Another one I found recently when I went to submit my Librarian application to the App Store was that the bundle identifier in the Info.plist cannot have a wildcard or any other character that would be illegal for a domain name, even if your provisioning profile uses a wildcard.
Since I had originally created a wildcard provisioning profile, I was using the wildcard for local development:
com.guidanceisinternal.*
I was able to build to both the simulator and the device with this.
After using the keyword for the current app name in place of the wildcard the App Store accepted my submission:
com.guidanceisinternal.${PRODUCT_NAME:identifier}
Hope this helps someone!
When submitting an App for approval, you have to enter the “Availability Date” in iTunes Connect. The default is the day you are submitting the App. If you leave it as the default and the App is approved 5 days later, the Availability Date doesn’t get automatically adjusted. It stays at the original date. The problem with that is, it doesn’t show up in front of the App Store’s new releases list which is sorted by Release Date.
I want this date to be set to the day the app gets approved. But without knowing how long it takes for the approval process, it is hard to figure out what date to set. Any suggestions?
“7. Set correct provisioning profile everywhere.”: setting the provisioning profile for the target in the current configuration should be enough (it works for all our projects) as it overrides the more general project settings. Think of it as just an extra layer to override defaults defined at project level.
Ramses, Really?? It’s certainly disconcerting that those two settings don’t match up. I could have sworn that if either one of them was off, the build wouldn’t be recognized by the device. But maybe the target one was the one that was off. I’ll double check.
Vic: Once your app gets accepted, you go into iTunes Connect, choose “Edit Application”, go to the Pricing page and change the date there to the current date. You do the same for every update that you publish too.
I am quite sure Ramses is correct. The target settings should override the Project settings.
An extra tip: I made it a habit to always go nuclear and delete the complete build/ directory in the Finder before building for the App Store. I have had inexplicable upload failures several times before and since I started doing this every upload has worked fine.
I want to put apps on App Store but I wonder about privacy and registering as an individual vs. registering as a business. I’d rather not share my home address and home phone number with everyone who visits app store, even those who buy my app. Is your personal contact information kept private? Or if you register as a business using a mailbox address does Apple require mountains of documents to prove that is your business address? Do you have to settle these matters before you can even test your app?
I don’t zip up my apps to send to people anymore. It’s easier to drop your app into itunes yourself and grab the resultant .ipa file from the the ~/Music/iTunes/”Mobile Applications” directory. That file will work for both windows and osx users. It also seems to confuse itunes less when a tester drops it in.
I also have never encountered #7. I’ve heard people say the same thing about submitting for the app store, but I’ve not encountered a problem there either.