How I Made My First iPhone App… Or, How Not to Make Your First iPhone App

FieldTrip, my first mobile app offering, is complete and, boy, the learning curve was sharper than Steve Job’s acid washed jeans. Here is a brief look into my development process, what I’ll never do again, and what I will do for the next one. Hopefully it will help new app developers get started.

Nerd up!

As this was my first app, I did not hit the ground running. It was more of a slow crawl with frequent, whiny breaks. About a year ago I purchased a book titled “Beginning iPhone 3 Development: Exploring the iPhone SDK“. After reading and working through the first few chapters, I realized that the book required a basic knowledge of Objective-C which I did not have. Learning a language is much different than learning a platform so the book was shelved in hopes that I’d soon have time to come back to it after figuring out Objective-C. Much like John Travolta’s 3rd wind acting career, I never happened. It was my Battlefield Earth.

A few months later I began to experiment with web based iPhone app development. With this method, an app is essentially a web view and the code is similar to a website. This lead me to PhoneGap and jQTouch. Both worked pretty well, especially in combination, but could not create a truly native application as they were webkit based. Webkit also meant that apps couldn’t take advantage of the phone’s hardware. No camera, push notifications, accelerometer, GPS, etc. All smoke but no fire. A point driven home by Apple when they began cracking down on non-native apps.

Courtesy appcelerator.com

Another few months more and I found Appcelerator. With Appcelerator, applications are created with javascript (a familiar language to us web devers) and compiled into native applications using their magic application and xcode. The brain of the app remains javascript but the application UI and database is fully native and you get access to all the phone’s hardware. Booyah! With this new toy, I set off to work.

New to Appcelerator, and forgetting all 10 years of real world practice, I started out in code to create my app. I knew more or less what I wanted. What could go wrong. Bad, bad move buttercup. I knew better but was drunk with Javascript power.

This type-happy start led to 7 complete rewrites as I delved deeper into Appcelerator and its best practices. It was yet another reminded that planning trumps passion. Rockstar.

Here’s how it went down:

• 3 rewrites before realizing, maybe I should wireframe this mother.. like all other projects I work on.
• 2 rewrites after actual testing a fully functional wireframe prototype, on a few users. Again, stupid move on doing this so late as holes in functionality and usability were uncovered which made rewrites necessary.
• 1 rewrite after deciding to design based on the wireframes and mash it into my code. I plead temporary insanity.
• 1 final rewrite to consolidate my code, properly create my views and elements to account for all functionality, and incorporate design systematically instead of the french press method. Side note, French Press sounds like a really badass wrestling move.

The end result is an app that works great and I’m very proud of. The lesson is this. Figure out what you’re doing before you start doing anything. With that little tidbit I could have cut development time by a month.

For the next app, my process will be as follows:

• Define the feature list up front. Figure out what the app does before starting. If not, the app will take on a life of its own in development and I’ll find myself adding sound effects, hardware vibration and unicorns.
• Sketch wireframes in pencil to sort out how a user will navigate and interact with the app. This will also define how many templates are needed. Remember to use pencil as it will allow for continual refinement of the experience and, as the ideas keep coming, keep me from worrying about alignment, fonts, and how large a certain field may be.
  
• Take the refrigerator worthy sketches and create refined wireframes. Check them to make sure all necessary views are accounted for then test them. Either create a quick clickable website, use MockFlow, or open Photoshop and let someone pretend to touch.
  While someone is reviewing the wireframes, I’ll keep my mouth shut and will not explain to them what they should be doing. A user should be able to use the app without being told what to do.
  
• Take the feedback, make adjustments and repeat the wireframing step. Expect to change how the views look and connect to one another at least once. If there are no updates, either I’m a user experience god or didn’t really listen to feedback.
  Don’t design until the wireframes are completely locked down. Developers tend to see things in ways that real users do not so I need to build for a users and not for myself.
  
• Make those wireframes into the best damned designs I can muster. If I suck at design, get help. While it does matters how fast a table loads or how streamlined database queries are, if a potential customer looks at the screenshots on the App Store and throws up a little, they’ll never see the results of all that coding awesomeness.
  

This is what I’ll do next and I hope it helps you get out there, make that first app, and lose less hair in the process. Leave a comment with your thoughts or experience. I’d love to hear them.