Mobile Orchard, a new blog covering iPhone and Android development, posted a great interview with Hampton Catlin this week to kick off the Mobile Orchard Podcast series.
Hampton Catlin of Unspace is probably best known in the Rails community for HAML, Sass, and Make Resourceful. He recently launched his first iPhone app, iWik iPedia. iPedia is a $0.99 Wikipedia browser that has sold over 50,000 copies so far. In this interview, Hampton talks about building the app, the process of working with Apple and the App Store, and more. If you’ve thought about building an iPhone app, this interview is definitely worth your time.
Mobile Orchard was created by Dan Grigsby and Peter Cooper. Peter is best known for Ruby Inside and a book on Ruby. Dan Grigsby is a Rail Spikes blogger emeritus, entrepreneur, and Ruby/Haskell/iPhone hacker. So far, the content is a good mix of iPhone news and original content (like the podcast, and a video walkthrough of an early Android phone). Knowing Dan and Peter, this blog should be worth a spot in any aspiring mobile developer’s feed reader.
Why mobile development?
I don’t know about you, but I’m feeling the draw of mobile development. Luke is too. So are Hampton, Dan, and lots of other folks in (and out of) the Ruby community.
Why is this? After all, mobile app development is a lot more like building desktop apps than like building web apps. Take the iPhone: desktop Cocoa programmers have a huge head start over us web programmers. You have to use low-level languages like Objective-C. You’re locked into a closed and developer-ambivalent (sometimes developer-unfriendly) platform.
So why move from the web to the iPhone? There are good reasons.
1. It’s different.
Building an iPhone app is very different than building a Rails web app. For some developers, this is a problem. We call those people bad developers. Good developers build software, not Ruby/Java/Lisp/Blubb code. In other words, they’re not interested in mastering a single tool and staying there as long as they can. They may specialize, certainly – become a really really good Ruby/Java/Lisp/Blub developer – but don’t stop there. The Pragmatic Programmer famously recommends learning a new language every year, and this is great advice.
So why the iPhone? Because there is something to be said for learning languages and tools at opposite ends of the spectrum. Should a Ruby developer learn Python, a reasonably close cousin? Maybe, in order to learn the quirks of Ruby and to find other approaches to similar problems. But should a developer learn Ruby, Python, Perl, Lua, and PHP? Probably not, because these languages are largely redundant, and there is more to software than just dynamic high-level languages.
Learning Cocoa and Objective-C doesn’t just teach new approaches to the same problems – it teaches new approaches to new problems.
2. It’s a framework.
Web application developers these days are used to using frameworks. So while Cocoa and Rails have little in common, the approach of using a framework like Cocoa is comfortable to web app developers. Unlike, perhaps, moving from Rails to raw C++ or raw Haskell.
3. Money!
Success stories like Hampton’s always catch the eye of a certain class of developers. These developers used to run micro-ISVs. (Remember that term?) Nowadays, they often gravitate to Ruby or Python or PHP. They aren’t looking for a stable career at a big organization, and they aren’t looking for VC funding or an IPO. They just want to build cool things and make some money from it.
The iPhone App Store caters to this type of developer. Setting aside for a minute Apple’s benevolent (or s/ben/mal?) dictatorship over the App Store, the whole focus is on helping people monetize their applications. The entrepreneurial developer’s dream is to:
- build something cool
- in a reasonably short amount of time
- and make money from it on an ongoing basis with minimal marketing and maintenance.
That’s what the App Store is all about.
4. Ride the growth trends.
The web was a huge growth trend in the late 1990’s, and again over the past few years, in new-and-improved “2.0” form. Whenever possible, it’s smart to ride this momentum.
Is “mobile” a growth trend today? It looks like it, and a lot of people are betting that it is. But more on that in a minute.
5. Diversify.
If you’ve focused on Rails development for the last few years, you might be feeling the need to expand your portfolio. There is still a lot of Rails work out there, and are still a lot of interesting web apps to build. But most of us won’t be doing the same thing in 5 years than we’re doing today, and learning another marketable skill is always helpful. Which would you rather have on your resume?
- Rails developer since 2005
Or
- Rails developer since 2005
- Ajax developer since 2006
- Merb developer since 2007
- iPhone developer since 2008
- Next Big Thing developer since 2009
I’ll take the latter.
Trend or bubble?
The App Store has been a worthwhile platform for Hampton and lots of other developers. My question is this: will that continue? Are App Store sales on the decline, now that the novelty has worn off; or will they increase over time? Think of Facebook Apps: for about 3 months, even the stupidest Facebook App was made of gold. (Especially the stupidest?) But now there are tens of thousands of Facebook apps that haven’t gone anywhere, and the growth stage is over. For now, at least.
The traditional growth model for successful ventures looks like this. The App Store skipped the early stage (slow growth, waiting for traction) and jumped right to the vertical bit of the hockey stick. But rapid growth can’t continue forever, and eventually even IBM and Microsoft are no longer growth companies. That’s the top part of the idealized growth model.
So where are iPhone apps? Do they have years of growth in front of them, or is the boom over?
Great post, Jon. I think you’ve really hit the nail on the head.
Interesting in light of O’Reilly’s iPhone Live conference cancellation. Bummer! I was idly thinking of attending that, especially in light of the lifting of the NDA.
Awesome post (though I might be a little bias). Thanks for mentioning us.
You raise some interesting points on the whole professional development front. Even though Ruby isn’t a viable language for iPhone development (at this point), it still makes sense for pragmatic Rubyists to be dabbling in the cutting edge – hopefully this post, along with Mobile Orchard, will encourage them to do so!
Speaking entirely based on my own opinion, I always thought Facebook apps were slow, not particularly good or interesting or even fun, and in fact just added clutter to a platform I otherwise use every day and adore.
iPhone apps on the other hand likely have a stable future that will be measured in terms of years rather than months, simply because it’s a closed loop that doesn’t rely on dwindling advertising revenues. That it’s tied into an iTunes account for consolidated billing is just a home run IMHO.
Remember, people our age have a hard time understanding why “kids” pay for ring tones, yet it’s a huge revenue generator for the carriers. As long as Apple keeps the complexity down and units sell, then iPhone apps are a safe bet.
Specifically, iPhone apps that are really just Safari instances inside an app shell (like iWik) are a safer bet, because you can easily target multiple front-ends with little or no modification to the infrastructure.
I expect to see a lot more discussion about this style of development going forward.
This is a pretty good list of some the reasons I’ve been spending my evenings hacking in XCode. Another reason is that it really is a fun &capable platform. It’s the closest thing we have to a Tricorder in 2008!
I think we’re really just starting to see the beginning of many innovative apps the iphone will enable.
iPhone is a boring, closed, proprietary mess.
I want Ruby on Android!
@Ian:
It is possibly that JRuby AOT compilation would work on Android as-is. I haven’t tried it yet.
JRuby interpreted on the phone, with JIT, probably won’t work, since JRuby will generate regular Java VM bytecode, rather than the Dalvik VM bytecode that’s needed on a ‘droid. I have no idea how difficult it would be for JRuby to incorporate context-sensitive bytecode generation and add support for Dalvik, though it feels like a lot of work.
Great blog, you pose a good question at the end about the growth of iPhone apps. Part of me thinks that we are quickly approaching the end of the boom…However, much like Web 2.0 I would not be surprised to see a mobile equivalent to web 2.0 emerge within a 2-3 years.
I’m thinking there’s something to do with Mohrs Law here? Or maybe its because cell phone service contracts seem to last for 2 years at a time, followed by some sort of ‘free/reduced price’ promo for a new phone.
I guess what I’m trying to say is that within 2-4 years a lot of people will have iphone/android successor type phones and after this point we will probably be breaking into the next piece of ‘everyware’ [http://en.wikipedia.org/wiki/Ubiquitous_computing].
@Ian and @Mark Murphy: Quick clarification on Android…
- Precompiled is definitely possible and probably the best way to get it working with a minimal footprint - Interpreted could work, but interpreter + parser go hand-in-hand and would probably be too slow. Only JIT would be impossible, since we can’t (yet?) generate Dalvik code at runtime.
JRuby users are very interested in making this happen, but there’s no resources available at the moment to do it.