ruby! food! kids! … and other fun from terry heath
RSS icon Email icon Home icon
  • My First iOS App: A Retrospective

    Posted on May 22nd, 2012 terry No comments

    I followed the advice in the 4 hour workweek blog about creating my own app. On 10May12, I had my idea. I designed it over the next two days, and on the second day also posted job specs to some freelancing sites. Today it was published! You can view it here: Green Light Timeout.

    So, overall, a pretty quick turnaround. There’s a ton of stuff that I learned from this, though, so my next app should be better / cheaper / faster / etc.

    Research

    The app I wanted would be a timeout app for parents to show their kids their progress through timeout. A continuing source of frustration throughout this process, I used different devices at different points in time.

    When I was looking for competing apps, I looked on the iPad. I didn’t limit searches to apps only made for the iPad, but if you search on the app store using an iPad, it shows those apps first, which biased my research.

    As such, I didn’t have as good an understanding of what apps were already out there, what they did well, what they didn’t, and how I could make mine better. Fortunately (if I may say so, not so humbly), my app’s simpler than the ones I found, so I got a little lucky.

    Design

    I used the Blueprint app for the iPad to design the application. It’s fantastic, and I think made the spec I provided to the developer significantly more coherent and manageable. The questions the developer asked weren’t trivial or meant to clarify obvious functionality, and I give most of that credit to Blueprint.

    That said, since I’ve never done any iOS development before, I didn’t realize that a lot of things that Blueprint made easy (say, gradient buttons), aren’t apparently as easy to drag & drop in XCode. So there was a little bit of a delay in development where the developer was waiting for me to provide the right assets for the app (button backgrounds, the stoplight, etc).

    As far as technical specs, I think the more (useful) information you can provide, the more time you’ll end up saving. I wanted charting in my app. There’s a great, free library out there called core-plot, but if I hadn’t told the developer about it, I’m not sure he would have found it, and would have either spent time finding a library that does what I mocked up, or would have tried to write one himself, which would have been painful (both for him and for my wallet).

    Hiring

    Hiring a developer wasn’t as fun as I thought it would be, and I’m naturally impatient, which made things worse. First off, don’t rush to hire someone. In the whole scheme of things, a few days isn’t a big deal, and wasting a decent amount of money on a shitty developer hurts more than waiting through the weekend.
    I posted jobs to Freelancer and oDesk, and the oDesk responses I got were more impressive, though there were fewer of them (I think I had 3 oDesk applicants and 9 Freelancer applicants).

    You’re going to get a lot of bullshit submitted to you. You’ll also get a lot of recruiters/software shops, which aren’t necessarily bad, but it takes longer to figure out if you’re working with anyone competent that way.

    I asked a coding question in my job posting, and the first email I received that included an answer got me really excited. I wanted to rush back from lunch and talk to him. Then, when I actually opened the full message (Freelancer didn’t send the entire contents of the message to me), it was dead wrong. Not even “oh I could excuse it by …” wrong — totally, absolutely, unacceptably wrong.

    If you’re not a developer, ask one you know for a simple “FizzBuzz” style question. Then either find a way to vet the answers yourself or ask the developer to do it – if someone can’t code something that should take 30 seconds when they have all the time in the world (remember, they’re applying to *your* job), you don’t want to pay them.

    Development

    Once development started, the turnaround time was fantastic. I had apps packaged and sent to me daily.

    This wasn’t how I wanted to work, however. I tried to get the developer to use GitHub, because it has a lot of handy built in project management stuff (wikis, issue tracking, file repository, *git*) and I could review code changes that way.

    On the job posting, I said experience with git is a must, but I didn’t interview on that point. As such… he never learned how to use git. A lot of developers will have experience with Subversion, and GitHub provides a Subversion interface to their repositories, so instead of fighting with the next developer I hire, I’ll probably just show them the svn hookup and get what I want with little friction.

    I entered issues into the GitHub issue tracker and showed the developer how to use them, and that worked really well. Using GitHub’s milestones, I was able to figure out what needed to be done before we could release, and kept things on target. If you haven’t opened bugs before or worked with an issue tracking system, Joel Spolsky has one of the best articles on bug tracking out there.

    Overall, it took the guy 38 hours to code the app. It was longer than I’d hoped, but I realized towards the end that my expectations weren’t realistic.

    oDesk provides some pretty cool management tools when you’re working with developers. It takes screenshots of their desktop periodically for any time they want to bill you, which is great, since I could look to make sure I wasn’t funding someone else’s development. I saw the guy used Facebook and applied to other posts, but it didn’t bother me since the majority of the pictures show development on my app.

    Testing

    When I was testing the app, I used the simulator almost exclusively. It takes nice screenshots, it’s fast, easy to get running, etc.

    It turns out this was a huge mistake. The iOS simulator doesn’t (or at least I didn’t have it set up correctly) have power saving settings. Remember, my app is for showing kids their progress in timeout. My son is almost 5, so that’s 5 minutes, but the phone’s screen turned off after 1 minute. Now he couldn’t see the stoplight, and the app pauses if you leave the screen, so timeout stopped.

    I didn’t find this bug until after I’d ended the contract on oDesk, and I didn’t want to spend another $15 to fix it, so I found the right methods to call and did it myself. So, there, I coded 2 lines in the app.

    But the important lesson here is to use your app for at least a day on the device you’re planning to use it on. There’s no point submitting something super buggy to the app store; either you’ll get lucky and it’ll get rejected, or you won’t and it’ll get reamed by user ratings.

    Conclusion

    Overall, this was a blast. I really liked designing the app, working with another developer (I try not to spend too much of my off hours coding), figuring out how to make things look nice and feel usable and keep things under budget (if I’d spent over $1000 getting this built, I’m pretty sure it would have been my last – turned out it was about $600, so not bad at all).

    I’m not sure it’ll make money, but it was an invaluable learning experience. I’ll do it again. Feel free to go buy it and give it a nice rating :)

    Comments are closed.