The “One Day” iPhone App Experiment

I’ve been working full time on an iPhone app for the last three months. Realistically, I still have another month ahead of me. Four months is nothing compared to projects for current game consoles, but it’s pretty long for an iPhone app. It’s not like I’m slacking off (I swear that playing WoW has nothing to do with it!), but it’s a relatively complex project for an iPhone, involving 3D graphics, procedural geometry generation, custom user interface, and network access among other things. Definitely not your everyday, quick iPhone app.

A couple of weeks ago, I decided to take a few days off from my project to enjoy the holidays with friends and family. Of course, I couldn’t stop thinking about the project. Soon my thoughts turned to how much more I had to go, and how some parts of the development process were still unknown to me, like the Apple submission process, or making a build for distribution on the App Store.

At that point, inspiration struck, and I decided to use one day during the holidays to write a quick, one-day app. That way it wouldn’t take any time away from my project and I would learn a lot from it. And maybe, just maybe, I would make a buck or two in the process.

The app itself was a very simple tea timer, inspired by tea maker machines: Enter the type of tea you want, the strength, and whether it’s loose leaves or in a bag, and it starts a timer with the correct steeping time for that particular tea. This was such a simple app, that it ended being exactly the way I had visualized the first time I thought about it.

Coding The App

Just coding the app itself was an interesting learning experience. Up until that point, I had spent most of my time on the OpenGL side of the iPhone. Tea Time! on the other hand, was 100% Cocoa Touch, so that was a nice change of pace.

Why did it take me a day? It’s such a trivial app that I should be able to throw it together in a few hours, right? Not quite. I had to deal with all the little quirks of Cocoa Touch, and get around the crippled functionality that Apple exposes in their API (while their own apps use a different API).

For example, it was a bit of a letdown to see I couldn’t add images to the picker control. But my disappointment was immediately replaced with excitement when I saw how easy it was to subclass it and display whatever you wanted in it. Unfortunately, the excitement gave way to annoyance trying to work around some of the bugs Apple still has on the picker control.

It’s really frustrating not having access to the same API Apple uses internally. I wanted to be able to turn off the iPhone while the timer was counting down, and have the device turn back on when the timer ends, just like the built-in alarm. Oh no, can’t do. Apparently that’s reserved for Apple. Fortunately, the longest you’re going to steep a cup of tea is 6-7 minutes, so I just disabled the power-saving feature of the iPhone so it doesn’t go to sleep while it’s counting down.

Even for such a simple application, getting a polished user interface in place takes some effort and time. The Interface Builder allows me to throw a user interface together in a snap just to get the basic functionality up and running. Later, I can come back and tweak it until I’m happy with it. Surprisingly, there are lots of things that the Interface Builder doesn’t allow you to do, so a lot of controls have extra code to tweak some of their parameters (increasing the target area of the info button on the top right corner, or setting the background images for he start/stop buttons, which require a special stretching pattern). Looking on the bright side, it’s very easy to combine a layout from the Interface Builder with custom code, which is a very important lesson for content-creation tools of any kind (and one that a lot of game tools get wrong!).

The rest of the coding time went into all the little things we don’t usually think about: Saving preferences, remembering the last used combination of parameters, getting the right splash screen, etc. All in all, the coding was about a day’s worth of work.

Creating The Content

There’s more to an app than code and a nice GUI layout, especially if you don’t want it to look like a boring spreadsheet: Graphics and sounds. In my first pass, while I was coding the basic functionality, I just grabbed whatever images I found through Google Images and threw them in. Then, once the app was pretty much finished, I set to replace them.

Original photo of my tea cup that became the icon for Tea Time!

That’s harder than it sounds because I’m not a graphic designer. I’m semi-proficient at the Gimp, but that’s about it. I do quite a bit of photography and I love tea though, so I decided to take pictures of the tea I was preparing at home. The main icon of for Tea Time! is just my tea mug with the tea I was having that morning.

The images had to be processed in the Gimp quite a bit. Tweaked colors and brightness, removed background objects, and even altered to fit the constraints of the GUI. For example, the little cups in the picker are the same picture that was then carefully colorized in the Gimp to match different tea types.

For the alarm sound, I was hoping to be able to play the system alarm sounds that come with the iPhone. But again, Apple lets us down by not giving us access to those (Why not???). So I hit a couple web sites with free sounds, selected a few that I liked, and tweaked them with Audacity to get the right length and sampling rate.

It was a really fun process getting all the content ready. I really enjoyed it and it was a nice break from coding, but it sucked almost another full day of work. So my “one day” app, was already almost up to two days. But at least I was done now. Right?

Submitting The App

I had done ad-hoc builds before, but I hadn’t prepared one for submission to the App Store. So I had to figure that out: Create a new distribution certificate, create a new configuration in XCode, test it… Not too bad.

Then I had to sign up for iTunes Connect and agree to a bunch of legalese non-sense. It was all done online and really quick, so that wasn’t a problem either. Finally I was ready to submit the app and be done with it. I had to write up a description, figure out the categories it would be listed under, take screenshots, and prepare a high-res cover art. I get all that ready, I fill out the submission form, and press submit. Done!

Oh wait, I get a message about not being able to get paid until I get a contract in place. What? Apparently when I signed up for iPhone development that only covered free applications, but I needed to set up a new contract in place with Apple if I was going to sell anything. So I had to enter bank ids, account numbers, tax information, and everything else. Once all that information was in place, my contract was in “Reviewing” state, and a couple days later it was approved without any hitches. Be warned that if you’re not in the US, apparently you have to mail a physical form to them before they approve the contract, so the process is likely to be much longer.

Along with the price (a very obvious $0.99), I had to set the “Availability date” for the app. I had read horror stories of developers who finally had their app approved, just to find it buried ten pages into the “New Releases” list in iTunes. The guys over at Veiled Games, explained how the release date is a combination of when the app is approved and the availability date you set. So I set the availability date to two weeks in the future and was ready to tweak it if necessary.

Are we done yet? Not quite. The submission page wanted a URL for a web page describing the app, and I didn’t have anything ready. I didn’t want to just point to a page in this blog, and I had been thinking that I should set up a company as a real legal entity for doing iPhone development and consulting. Fortunately, I had gone through this process before with Power of Two Games, so it was relatively easy and painless, especially since this was a single-member LLC. So the rest of the day was spent coming up with a company name (Snappy Touch), registering the domain (http://snappytouch.com), registering the LLC (in the state of Oregon no less because it’s a lot cheaper than California), installing WordPress in the new domain, and setting up a basic page describing Tea Time!.

Finally done! Total time: Three days.

Waiting And Waiting

But Tea Time! wasn’t on the App Store yet. It had just entered the review process. Now I had to wait for Apple to approve it (or reject it so I can fix it). I heard from other developers that the usual wait time was about two weeks, but between this coinciding with the new year, and Apple getting swamped with submissions for the holidays, I figured I would be more like three or four weeks. Glad nothing was riding on this app getting out quickly.

A few days later, when I was checking out the info for Tea Timer! in the Apple submission site, while it was still in review, I was shocked to see it was listed as requiring SDK 2.2. That made no sense! I made a point to develop it for SDK 2.0 so every iPhone and iPod Touch user could buy it. I made really sure I selected SDK 2.0 when I created the iTunes distribution build. What gives? Apparently just building against SDK 2.0 wasn’t enough. I actually had to change the project settings to set SDK 2.0 as the default. That’s a sneaky one!

So what to do? I rejected my own binary and uploaded a new, updated one. This one was correctly listed as requiring SDK 2.0. I wasn’t too happy at having to do that because I’m sure it put me back to the end of the line, but this is exactly the kind of thing I was hoping to learn with Tea Time! in a no-pressure situation.

Waiting is no fun, so I made things a bit more interesting. Since I had gone to the trouble of creating a legal company, I decided to change my Apple Developer account to be a company instead of an individual. That way the company information would show up correctly in iTunes whenever Tea Time! was available. I figured this would be a matter of checking off a checkbox in my account settings, but apparently not. I had to email the Apple Developer Connection support with the request, wait a few days for an answer, and then provide some legal proof that the company existed (like the articles of incorporation). Once I emailed those, they initiated the conversion process, during which time I was locked out of my account for three days.  What does it take to change one bit in my account record??? Fortunately I had nothing else better to do than wait by this time, and it wasn’t impeding any work on my other project.

Finally!

The very next day after getting changed over as a company status, I got the much-awaited email from Apple announcing that Tea Time! was approved. That was just a week and a half after my initial submission. That was fast, especially considering I re-submitted the binary half way through. I reset my availability date to that day, and within a couple of hours, there it was, in the App Store. Mission accomplished!

Now, I get to learn about the sales reports, and, if I ever sell enough units, getting payments from Apple. They won’t make a payment until you accumulate at least $250 in profit from a single territory, so I’m not holding my breath for that one 🙂

The “one day” app really took three days of work plus a week and a half of waiting. All in all, two weeks from idea to the moment it was available on the App Store. The process could be faster, but it wasn’t too bad. The experience was a lot of fun, and I certainly learned a lot from my mistakes and what things to watch out for next time, when it really counts.