Jonathan Stark

PPK recently blogged that his clients are hellbent on having apps in the iTunes app store – whether it makes sense for their business or not:

Right now nobody’s interested in a mobile solution that does not contain the words “iPhone” and “app” and that is not submitted to a closed environment where it competes with approximately 2,437 similar mobile solutions.

His post goes on to assert that in many (most?) cases, the business needs of the customer would be better met with a web app than a native iPhone app:

I am convinced that the HTML5 app route is the best one for a fat slice of the non-game iPhone apps currently out there, especially those that are simple and face stiff competition. Increased interoperability will help them more than a relative lack of eye candy will hinder them.

I totally agree with this. Like PPK, I have observed in my clients a blind exuberance for iPhone apps and the iTunes App Store. In my experience, this desire for a native iPhone app is sometimes warranted because it would be infeasible to build the app using HTML, CSS, and JavaScript. However, in the vast majority of cases the apps that my clients want can be built better, faster, and cheaper using standard web technologies.

PPK – for whom I have a deep and abiding respect, btw – suggests that the solution to this issue is to popularize the phrase “HTML5 Apps” as a buzzword. I suspect his post is a bit tongue-in-cheek, but taken at face value this approach seems decidedly cynical to me because it’s predicated on the notion that clients are easily manipulated. In a word, simpletons.

I admit that my clients are typically not very knowledgeable when it comes to software development, mobile or otherwise. However, this does not make them simpletons, any more than my lack of knowledge about the inner workings of the FedEx delivery chain makes me a simpleton.

Clients are experts about their business, their customers, and their budget. They don’t know much about the inner workings of mobile apps, and they don’t need to – that’s why they hire people like me (thankfully!).

When a client comes to me wanting an “iPhone app,” my first step is to determine whether they are using the term “iPhone app” literally, or as a synonym for “mobile app.” It’s as simple as asking:

“Do you want your app to run just on iPhone, or other phones too?”

They almost always respond by saying that iPhone is important, but that it would be great if it ran on other phones as well.

NOTE: I have a bit of a bias here because I consult with large companies that have a very broad user base. As such, they always want the app to run on iPhone, Android, and Blackberry at a minimum.

Throughout the course of my initial discussions with a prospective client, my primary goal is to learn why they want the app built, as opposed to what they want the app to do. Once I know why they want the app (i.e. their goal) I can make a judgement as to whether I can achieve that goal for them. If I believe that I can do it, I’ll write up a quote and we’re off to the races.

Here’s the thing – at no point do I feel compelled to discuss *how* I’m going to achieve the goal. Whether I build the app with HTML, CSS, and JavaScript, or Objective-C is irrelevant to the client. All they care about is that their goal is reached.

And yes, there are some exceptions. Sometimes I have a client who does understand the inner workings of mobile apps. In this case, I’m more than happy to invite them into the decision about what technologies should be used to build the app. We can get into the pros and cons of native apps, versus web apps, versus native web apps built with PhoneGap, etc… But again, clients don’t usually care about that sort of thing. They just want it to work.

Ultimately, I think that the distinction between web apps and native apps exists mostly in the minds of developers. To clients, they are all just mobile apps. My suggestion to mobile developers is to sidestep the issue completely by achieving your client’s goals using whatever tools you feel are right for the job.