Musings from a hobbyist iOS developer

I got this hair-brained idea a little over a year ago that I was going to develop apps for iOS in my spare time. The crazy part of the idea wasn’t that I was going to learn Objective C, it was that I actually had spare time. So over a year into it how am I doing and how does one measure success for a spare time endeavor?

My First App: Rejected

I got into iOS app development with a very specific application that I wanted to develop. However, as I started getting into learning how to code for iOS I realized that the app I really wanted to develop was too tall of an order for my first time at bat. So in the middle of my self-induced training I found a big hole in the App Store where a very simple application that was within my capabilities to develop could fill the void. What I didn’t realize at the time was that I had chosen to develop an application in a category that Apple had deemed saturated. Had I read through ALL of the developer documentation I would have known this ahead of time, but honesty I would have developed the app anyway. Why? Because the app I was developing was truly unique and was bringing functionality that did not exist in any form within the App Store. Unfortunately Apple doesn’t make app approval decisions based on an individual application’s merits (at least in terms of this particular guideline) and they shouldn’t. Apple can’t afford to at this point. There are a couple of app categories in the App Store that are so over saturated that even if you developed the best and most original app within that category it would be lost to the void the second it was released. So where does this leave me? It actually leaves me in a better place. Developing that app (even though it was rejected) gave me the confidence that I can actually do this app development thing. It also left me with fucntionality that I can use as part of another app (to be develeoped in the future) in a different app category. That app will at least have a fighting chance of being successful instead of getting lost in the noise of an over-saturated app category.

Success or Failure?

I want to address this question of success or failure. There has always been a fine line between success and failure. One one hand I failed to release my first app on the App Store, but that’s not what I set out to do was it? My goal was to develop apps for iOS in my spare time, not the specific app that was rejected. Now you could say I’m just making up excuses to make myself feel better about being rejected. Maybe. But I contend that you have to look at the big picture. No single endeavor worth pursuing can be achieved without having some amount of failure along the way and app development is no different. I learned a tremendous number of things along the road to rejection and those things ultimately are going to help me be successful in the future. Here is what I have I learned:

  • The last 5% of the dev process is 95% of the work

  • The details are EVERYTHING when it comes to design

  • Never stray from the vision or the need behind developing the app in the first place

  • The last leg of releasing the app (ideally) should be more of a slow slog than a sprint

Forward From Here

For me this past 6 months (the time period I have been spending a respectable amount of time learning and developing) has been a good lesson in time management. If app development was my day job or at least represented a significant contribution to paying my bills this would be a totally different blog post…but I’m lucky enough to not be dependent on income from this pursuit. The down side to this is that I have to try and balance my very demanding career and (especially right now) my incredibly jam-packed family life/responsibilities. What I have taken away from this experience so far is that for a part time pursuit it is imperative that the activity remain as fun and creative as possible. As soon as pressures to produce or release something come into play the creativity and the drive for perfection starts to wane, and if you have caught on to the title of my blog site "half-way" is not something I am interested in doing. So going forward I am going to be learning and developing at a slower and flexible pace than what I was attempting before. I signed up for the Stanford University iTunesU course: “Coding Together: Developing Apps for iPhone and iPad (Winter 2013).” I also registered for an account on Piazza (a social learning platform) that allows students to post questions and discuss class problems in between assignments. For this particular session there are over 16,000 signed up for this particular class that are using Piazza to collaborate with other students. I started with the best intentions, but my other responsibilities made it too difficult to keep up with the pace of the class. I am still on class session #3 and they just posted session #14. So it didn’t work out this time around, but I really like the added social component that Piazza brings to the table. I can see where a class like this will work really well for how I like to learn.

So while my iOS development may be on a slow-track right now, by allowing this to happen (and really being ok with it) I will be all that much more enthusiastic about it when all my other responsibilities allow me to indulge on this undertaking at a much faster pace in the future.

Single Vision for App Dev

My last blog post talked about the important of keeping the design of the app as simple as possible. In order to make some of the difficult decisions needed to ensure the app design stays true to its original intended purpose, you need to establish (BEFORE beginning to design and code the app) the main purpose or "need" for the application. The process I am about to describe is actually a process used by Systems Engineers to design and develop highly complex systems. The reason this process is used for complex systems is that without establishing this single and simple vision you can end up building the WRONG system. 

A need statement is nothing more than a very basic sentence or phrase that states why something is needed. The only rule that needs to be followed when developing this needs statement is that the statement can't have a solution built into it. For example, if you were writing a needs statement for a kitchen timer app the needs statement shouldn't contain the phrase "kitchen timer." Kitchen timer is a solution to the need to keep track of specific durations of time while cooking and preparing food. The reason for this rule of not stating a solution in the needs statement should become obvious in the next few steps of this process. 

Now that you have established the basic need, the next step is to list out important aspects you would like the solution to employ in order to meet the need. We call these goals and the goals should be high level strategies that are absolutely essential to meet the need. For the kitchen timer example, three goals of the solution might look something like this: 

  • Goal 1: Support both time duration and local time relative timing events
  • Goal 2: Provide non-visual information and feedback to the user
  • Goal 3: Minimize the need for the user to interact with touch gestures

Goal 1 is all about having the ability to set timers based on a time duration or a user defined time offset from the local time. For example, while cooking in the kitchen you may have a casserole in the oven for a certain duration and you might also want to start chilling some wine 30-minutes before the expected arrival time of the guests. Goals 2 and 3 are about the use case of physically cooking in the kitchen. You might not always be within view of your kitchen timer so having non-visual feedback (tones, alarms, voice messages and vibration) would be useful. In addition to moving all about the kitchen the user may also have their hands covered in food. A goal to minimize finger touch interface and maximize things like gestures (think of using the back of one of your knuckles to trigger a timer when your fingers are covered in goo). Voice commands could also be used to help meet this goal (can you say Siri API?).

We have arrived at the last piece of the vision for the solution we are aiming to design and that is the objectives. Objectives are simply ways to measure whether we have achieved the goals. Objectives are high level technical performance requirements, but more importantly they are a measuring stick to keep you honest as a developer. Typically these objectives are really important. If you find yourself during the design process worrying about other aspects of the design and you are aren't meeting your objectives you know you are focusing on the wrong things.

For the kitchen timer example, the following could be objects that address the goals we just created:

  • Objective 1: Timer function shall support 4 timers at once
  • Objective 2: Timer function shall support clock based timers
  • Objective 3: Timer function shall use 4 different vibration alerts
  • Objective 4: Timer function shall use 4 different alert tones
  • Objective 5: Timer function will respond to a swipe gesture
  • Objective 6: Timer touch target will be at least x pixels wide

So how does all of this fit together and help a developer focus on what's important? Below is how the objectives flow up into the goals and ultimately back to the need:

As you can see from the diagram, this exercise has created a very clear set of objectives that can be measured during app development. The examples shown here are greatly simplified. In reality you will end up with much more specific and more easily measurable quantities for your objectives. The important thing to take away from this is that spending a few hours fleshing something like this out for your next app could really pay-off when later down the road when you have to start makind critical design decisions. Remember, it should all link back to the basic need you are satifying with the app. If it doesn't, then you are going down the wrong path.

Yes, I am still workng on developing my 1st iOS app and no it's not a kitchen timer. When I release the app I'll post my needs, goals, and objectives and see if all of you and my customers agree that my app stayed focused on the need that spurred the creation of the app in the first place.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.