A few weeks ago, I set as my drop-dead, better-be-done-or-I-kill-myself date for Flower Garden to be March 20th. The date getting closer allowed me to focus and put a huge, hard effort. Since I got back from 360iDev, I’ve been working between 18 and 20 hours per day. Yes, that’s pretty crazy, but it actually didn’t feel like a strain because a) I love doing this and b) I can do it from the comfort of my own home. But that’s the topic for another post.

The point is that as March 20th approached, I was slaying bugs left and right. Flower Garden went through two rounds of beta testing and it had some great feedback. All the crash bugs and top priority tasks were done and taken care of a few days before the deadline. Things were looking good for a submission to Apple on the expected date! Yay!

Then, with just a day to go, I decided to step back a second. Something had been nagging at me for a bit and I had to be honest with myself. Yes, all the crashing bugs and major features were taken care of. But how come my issue tracking system still had 50 entries in it marked as “Final release”? It wasn’t a big deal. Those were all marked as “low priority” or “trivial”. And that’s the great thing about the iPhone, I can submit the application and then start pushing out updates as I get to the little stuff. Right? Right?

This wasn’t a case of taking Old Yeller behind the shed. The app was looking good. Really good. And it wasn’t just a puppy, but a fully grown, beautiful app. It’s just that it was a bit… slow and rough around the edges.

This is were things got really tough for me. On one hand, I was ready to ship this baby. I have been working on it for almost six months (where did time go??) and a lot of people were loving it. But when I allowed myself to give it one hard look, I realized that the experience I was hoping for wasn’t there. Yes, the functionality was there, but not the experience. With a tool that gets a job done, maybe that’s not a huge deal. But Flower Garden is all about the experience.

I tried to rationalize it by thinking how I could get all those little, low priority things done in an update right away: Improving the performance of the rendering, making the transitions more responsive, adding those subtle animations and sounds, making load times shorter… In short, it was missing the key ingredient to a successful experience: polish. I could always add that polish later, but what about all the people who bought it right away? What kind of impression were they going to get? In a saturated market like the iPhone App Store, and especially with a title aimed at a casual audience, first impressions are everything. If people don’t fall in love with your product right away, you might not get a second chance.

So it was with a very heavy heart that I decided to slip my target date. I really needed one more week to get to the point that Flower Garden could be the experience I had envisioned. And of course, to make it twice as hard, this coming week it’s GDC, so that means that the release date is pushed out two weeks.

Coming from the console world, where updating your game is a rare opportunity and you better get everything right for the big release,I was really counting on releasing frequent updates. Does it mean that updates are useless in the App Store? That we shouldn’t take advantage of them? Not at all. I realized that I was looking at them the wrong way. Updates are supposed to provide bug fixes and new functionality. They are not a crutch for sloppy development and an excuse to release products before they’re ready.

Now I have regrouped. Reassessed where I’m at, and prepared the final plan of attack. If all goes well, I will be submitting Flower Garden to the App Store the last week of Mark/beginning of April. When exactly? When it’s ready. Lesson learned.

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.