Pages

Thursday, November 26, 2009

My First iPhone App Submission

I just completed my first iPhone App for the App Store.

It's a Hockey Twitter app for tweeting about Hockey, specifically the NHL teams and games.

I'll post more info on the app later but for now I am going to cover tonight's submission process. The submission took about 3 hours. This was time spent reading Apple docs, filling out App submission paper work, reworking my icon (I had it in jpg not png), reworking my App Store icon (it was a little blurry so I sharpened it up), and redoing multiple builds.

To build I needed a Distribution certificate which I could have done before and saved some time tonight (lesson learned). The artwork is now solid (I hope) so I won't need to do that for this app again.

Overall the submission went fairly smoothly; I did get annoyed by a quirk in the submission pages which kept sending me back a page and losing data I had typed. This was very frustrating but once I figured out the issue I made it through without losing data.

I'm taking a couple days break before I jump back in and get back to work. I'll be recording a preview video, redoing the website, and posting a followup when I get through the review process.

I also have an article on the decisions I made during the app and how I choose various features and approached the design. That one is still cooking and will come later.

Next week is a big week as well, I am off to Toronto for the iPhone Tech Talk.

Did I mention? I just submitted my first iPhone App? (Me -> nervous, excited, tired...)

Saturday, November 21, 2009

Indie Software Development - You Need A Process

Process sucks. It slows you down.
Process rocks. It speeds up development.

It's a problem developers face all the time; how much process is enough? As a full-time industry developer working on large software systems with teams ranging from 10-500, process is important. Process helps you:
  • communicate
  • plan
  • deliver quality software
As an indie developer though, how does process help? First off perform the Joel Test: 12 Steps to Better Code. Joel's test is as important to any indie developer, even a one man shop, as it is to a large organization.

Crazy you say! One developer does not need a process!

Do you want to ship?

If the answer is yes, then you need a process.

I use process to help me:
  • keep track of what I need to do
  • tell me when I am done (when my original list of features is done)
  • help me deliver quality code
  • help me estimate future projects better
As a one man shop, I sometimes skipped process and it bites me. I then end up wasting time on rethinking what I have to get done.

On the other hand, when I follow my process I quickly know what I need to do. That said, I have adapted my process as I've learnt what works best. Here is what works best for me:
  • Source Control: git, it's free, it's easy, it's fast, I like it. I've heard complaints but so far it has served me well.
  • Specs: What am I building? I write Use Cases, sketch UI mockups, write a feature list, and I work out how the system will be implemented (web services, data structures, and data interfaces).
  • Bug Tracking: I use FogBugz; if you are a student or startup (2 people or less, like me) then you can use FogBugz for Free
  • Schedule: See previous for FogBugz
  • Functional Testing: I do it myself with a mix of unit testing, frequent code+test iterations of each new feature, and I solicit Beta-Testers to get feedback on devices/OS configurations I do not have. This is something I want to spend more time on to get a better balance of unit tests to ad-hoc testing. Currently I am doing more ad-hoc than unit tests and it bites me with wasted time.
  • Usability Testing: I show the app to lots of people, iPhone/Touch owners and non owners to get feedback on the UI. Is it intuitive? Is it fast? Does anything jump out at the user as bad/ugly/hard to use?
  • Bugs: Log them when I find them and fix them ASAP. I log them so that I can review what I have in my bug list before I move onto other code. I try to keep true to the rules of "Fix the First Problem First" and "Fix It When You Find It". This helps me stay focused on my task so I am not trying to work around things I know are broken. This wastes brain power.
That's my main process for a one man shop. It is how I keep things straight with only 1-3 hours/day to work on my projects. Working in small units of time means being efficient and coming up with ways to keep track of tasks that are usually in a mid-completed state.

As for how I manage to complete features that are larger than 1-3hrs, I use the tried and true technique of breaking the problem down. Basically:
  • Break features into smaller features.
  • Work on one feature at a time.
  • Test when feature is implemented.
  • Commit feature.
  • Rinse and repeat.
This works for me and let's me work on something that might take 10-15 hours of research, design, code, and test over several days. Without the frequent code/test/commit cycle I run into trouble trying to implement multiple features at one time, or trying to implement one large feature that could have been broken into many smaller features.

KISS (Keep It Simple Stupid) works for software development as well.

Thursday, November 19, 2009

iPhone User Experience + UIWebView

Beta and UX testing has given me a couple things to work on:
  • Bugs
  • UX
  • More bugs
Ok, the bugs are mostly found by me. The UX issues are things that people have mentioned when the use the app (UX=User Experience).

The first thing I do when I show someone the app for the first time is ask them to tell me the first things that come to mind about the usability. So far I've gotten 3 biggies that are worth investigating:
  1. Live feeds of information pertaining to the app so the user can drop that information into a tweet instantly without having to look it up or type it. Good one and something I will consider for a future release since sourcing the life feeds I would need will take time to build since I have not found anything with the information that the user thought would be most valuable.
  2. Customized tweet strings or tweet templates we will call it. Great idea and good for a future release.
  3. Last but not least; one tester pointed out I should really make signup for a Twitter account as easy as possible for a user that does not have an account. Good point, this should go into release 1 I think.
So, I thought let's add a UIWebView for the Twitter signup page. Adding the UIWebView was easy so I dropped it in immediately so the user can navigate to the Twitter Signup page within my app and quickly create an account.

Now, if I could just nail down the last of those bugs. Currently I have some unhappy plists which I am using to store cached webservice data between runs of the app. Off to track those down now.