Eran Kampf
Eran Kampf
6 min read

Building an iPhone Application - Lessons Building Fiddme

fiddme-teaser On the past few weeks I’ve been working on a new iPhone app – Fiddme. The process of building our app has been quite an adventure and we’ve experimented with several technologies that were new to us before reaching our current technology stack.
As we’ve finally got our stuff together and made an initial release to a group of testers I thought I’d share some of the technology choices we’ve made and the reasons behind them.

First some information about the team

…because technology choices are affected by the team’s technical skillset.

  • We’re 3 developers (Yosi, Udi and myself) and one designer (the awesome Naor Suki).
  • We’ve allocated two developers for the iPhone and one for the backend APIs & website.
  • We’re all veteran developers with experience mostly on Microsoft’s Development stack. This project meant going out of our comfort zone to a whole new set of technologies. Experience does make a difference easing the learning curve…

iPhone Development

  • iPhone SDK: This one is obvious right? We looked for alternatives for writing Objective-C. Unfortunately, Flash isn’t available for the iPhone (yet?) and MonoTouch looked promising but isn’t quite there…
    Besides its always better to be developing on the platform most developers are using which means there’s a big community that can help when you get stuck. Being on Apple’s official stack also means we get the latest features without having to wait for a 3rd party to convert them…
    To be perfectly honest, I’m not on the iPhone side of the development and did not actually write a single line of Objective-C code but I noticed it took my teammates 1-2 weeks to get the hang of it.
    To me, the fact that the iPhone App store is so successful and has so many apps which Objective-C as the development language (which is definitely harder than modern languages Java etc.) makes Apple’s achievement even more amazing…
  • Three20: Handful of UI extractions from the Facebook iPhone app and open-sourced by the developer joehewitt. His announcement blog post details the libraries it contains, shows some demos etc.
    The source code is also a great learning tool for how stuff is done on the iPhone.
  • json-framework: This is a pretty slick JSON parser for the iPhone. Hand parsing JSON in obj-C would not have been fun. This made it easy. I’m pretty sure I followed this tutorial to get it up and running.
  • ASIHttpRequest: A Nice Http framework that enabled easily handling asynchronous Http requests.
  • Stackoverflow is an invaluable resource for asking question and solving all sort of problems. As Yosi, who’s been concentrating on the iPhone side of our development, puts it “I don’t think any iPhone development could be done without StackOverflow”
  • MGTwitterEngine: an awesome objective-c wrapper for twitter api which we based our api on.
  • Google Analytics SDK: A library enabling sending information to Google Analytics from the iPhone. This is important for measuring the ways users interact with certain flows on our program. For example, it helps us measure the conversion on our signup flow how many users go through the signup flow and finish, and if they don’t, what steps makes them go away?
    This kind of functionality is essential to measuring and improving UX flows…
  • Google Toolbox for Mac: A library for working with the different services exposed by Google.
Backend Development

After playing around with ASP.NET MVC (which we all had background with having come from the Microsoft ecosystem) and Ruby on Rails (because its cheaper to host than ASP.NET and way simple, faster, more fun to use IMHO) we’ve finally settled for Google AppEngine and django (Python).

We made the decision to base our development on django rather than on Google’s own webapp framework for the following reasons:

  • Lots of out of-of-the-box features. django has been out there for quit a while and is bundled with lots of features (like an easy to build admin interface, authentication system, validation system etc.)
  • Big community. There are lots of people doing django out there lots of open source libraries and samples available. As a rule of thumb its always better to be on the majority side…
  • Not specific to Google AppEngine. django is a standalone Python web development platform. While some parts of our code has to be AppEngine specific it would still be considerably easier to move away from AppEngine (if we ever decide to do so) than if we were entirely Google specific.

Google AppEngine also have Java support. But using Python with django is way easier and has a lot more support when it comes to both AppEngine and web development. Seriously, if you’re thinking of using Java, Don’t! take the leap and go with Python…

Libraries we’ve used:

  • app-engine-patch: This library is absolutely amazing and a must if you’re using django on AppEngine. Since the AppEngine data store API is not compatible with django’s API, a lot of the really cool time-saving features of django will simply not run on AppEngine (such as the admin UI, authentication and basically anything that requires data access). app-engine-patch loads django and patches it so it is compatible with the AppEngine API making all those cool django features work. This one is a must! You just download their project template and start developing your application on top of it.
  • PyDev: An Eclipse plugin for editing and debugging Python and AppEngine applications. It might sound obvious but I was using was actually using Notepad++ (on Windows) for development until I found out there’s a decent IDE I could use…
  • Piston: a django library for developing REST-APIs. While its not entirely compatible with AppEngine it took a simple forking to edit those parts out…
  • GeoModel: provides basic indexing and querying of geospatial data on Google AppEngine.

Also, I would recommend taking the time to learn and understand how the AppEngine datastore works so you’ll understand how to build your datamodel to run efficiently on Google’s platform.
The following two presentations from Google I/O are invaluable:

So what do you think? If you’re developing an iPhone app, I’m very interested to know what were your technology choices and reasoning…

Oh, and if you have an iPhone and you live in Israel (its a local app so we’re limiting our efforts to Israel at the moment) please head over to our beta signup form and signup 🙂

    « iPhone vs. Droid High Performance at Massive Scale Lessons learned at Facebook »