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?

A few weeks ago I posted an article about developing iPhone web applications with Rails. Ben over at Slash Dot Dot has a nice article today that is more expansive than mine: iPhone on Rails.

Ben shows a nice trick for adding a fake subdomain to localhost using /etc/hosts. I would recommend that instead of what I was doing in my post.

Also, he links to a very nice Javascript/CSS library called iUi which simplifies creating native iPhone-esque web applications. Very cool!

iPhone! It seems like everyone has one, and those who don’t have one are talking about it. (I fall into the latter category.)

I recently attended an Apple iPhone Tech Talk with some of my colleagues from Slantwise. It was well worth it. I highly recommend going if the talk comes to your area. If you can’t attend, you can watch the videos online. Getting into the nitty-gritty of how to develop for the iPhone and iPod Touch was very interesting, but to me the most useful aspect of the class with the information on the iPhone web application user interface guidelines.

Most examples I’ve seen for how to do a special view for the iPhone suggest something like this:

1
2
3
4
5
6
7
8
9
10

class ApplicationController < ActionController::Base  

  before_filter :adjust_format_for_iphone

  def adjust_format_for_iphone
    if request.env["HTTP_USER_AGENT"] && request.env["HTTP_USER_AGENT"][/(iPhone|iPod)/]
      request.format = :iphone
    end
  end
end

However, Apple’s user interface guidelines for the iPhone suggest against doing user agent sniffing. The reason is that iPhone users are used to being able to use the entire web. They don’t want a limited subset.

Another problem is that when Apple releases a new device, your code will need to be updated to work with it. This actually happened when the iPod Touch was released. Some iPhone sites didn’t work on the iPod Touch because (unlike the code above) they only sniffed for “iPhone”.

When I was at the Apple iPhone Tech Talk, Apple suggested the best way to develop web applications for the iPhone was to provide the full version of your site, with a link to the iPhone web app. The iPhone version should focus on discrete functionality, and look like a native iPhone application. But if an iPhone user ever needs to use the “real” site, it’s just a clicks away. Examples of sites doing this include Facebook and Amazon)

Fortunately, this is still easy to do with Rails.

1
2
3
4
5
6
7
8
9
10

class ApplicationController < ActionController::Base  

  before_filter :adjust_format_for_iphone

  def adjust_format_for_iphone
    if request.subdomains.first == "iphone"
      request.format = :iphone
    end
  end
end

You can test that your subdomain detection works with something like this:

1
2
3
4
5

def test_hitting_app_using_iphone_subdomain_should_set_iphone_virtual_mime_type
  @request.host = "iphone.test.host"
  get :index
  assert_equal :iphone, @request.format.to_sym
end

This is kind of a drag to develop with, so when not in production mode, I sniff based on the user agent like the old way.

1
2
3
4
5
6
7
8

def adjust_format_for_iphone
  if request.subdomains.first == "iphone" || 
     (RAILS_ENV != "production" && 
      request.env["HTTP_USER_AGENT"] && 
      request.env["HTTP_USER_AGENT"][/(iPhone|iPod)/])
    request.format = :iphone
  end
end

With this, I can use iPhoney to test my code on localhost, but the sniffing isn’t used when deployed.

For those times when you do need user agent detection, Apple recommends testing the “Mobile/XX” part of MobileSafari’s user agent string. This will work across iPhone, iPod Touch, and future MobileSafari devices.

Here’s an AbstractRequest#iphone? method. You can use in in your views to display a message to iPhone users telling them about your iPhone-optimized site or web application (like Amazon does). But I’m not sure if this is the “Rails way” to do this. Let me know in the comments.

1
2
3
4
5
6
7

module ActionController
  class AbstractRequest
    def iphone?
      self.env["HTTP_USER_AGENT"] && self.env["HTTP_USER_AGENT"][/(Mobile\/.+Safari)/]
    end
  end
end

And of course, I used the above method to refactor my adjust_format_for_iphone method.

For more on this topic, check out the iPhone Dev Center. You have to be an ADC member to look at the content, but signing up is free.

Update: Check out Ben’s Slash Dot Dash article on iPhone on Rails – Creating an iPhone optimised version of your Rails site using iUI and Rails 2 for some new tips and tricks.