Pop quiz: What do the resurrection of long-extinct species of dinosaurs and iPhone app development have in common?

Answer:

“[They] were so preoccupied with whether or not they could, they didn’t stop to think if they should.” - Dr. Ian Malcolm (Jurassic Park, 1993)

Okay, so a poorly conceived iPhone application won't (necessarily) go on a murderous rampage slaughtering extras and supporting actors, but like the failed theme park, it will end with you flushing large amounts of money down the proverbial toilet.

Full disclosure: I am a registered Apple iPhone developer. I've loved both iPhones I've owned and I plan to buy another.

That said, I’m also a pragmatist who believes in using the right tool for the job, even if it’s not the bandwagon tool of the minute.

I'm not suggesting that there should be no app store, or that native iPhone apps are evil. However, it's important to realize that not all mobile applications would be best served as a native iPhone apps.

Problem #1: Barriers to entry and discovery
With the explosion in popularity of the iPhone and App Store, and the ubiquitous “there's an app for that” slogan, the past year has seen a veritable flood of new apps hit the market. Some apps are genuinely fun (Carcassonne), useful (AroundMe), or make clever use of the iPhone’s unique hardware (Zen Bound). However, there is a darker side which includes significant growth in the AppSpam/AppScam industries (such as the $199.99 Allergies Relieft app).

The App Store has a relatively high barrier to entry as it is. To even develop an app, at minimum you have to spend $99/yr on a developer's license, months of design, programming, and testing, and jump through hoops at every stage (register all testing devices, generate and install provisioning profiles, etc).

Once you have an app finished, then comes the nerve-wracking app store approval process where your app content and code are reviewed and can be rejected for any number of reasons including being too clever or for other, more obscure reasons.

After all of that, if your app made it into the App Store, it will most likely be swept away in the currents of the aforementioned app flood. The exceptional apps float to the surface for a brief gasp of air on the “Top” or “Featured” lists, while the rest quickly lose sight of the sun and wallow away in dark obscurity.

Additionally, the App Store does not really help that much in getting your app noticed. No matter what, you will still have to market your app to some extent.

Problem #2: iPhone apps are expensive to create
...and all of the available revenue streams (purchase price, in-app purchase, and in-app ads) are driven by popularity. If no one is downloading your app or running your app, you won't make any money on it.

Additionally, the bar has been set pretty high. Unless you have a lucky stroke of genius that gives your app some unique twist that causes it to go viral, your app will likely not be touched unless it is polished to within an inch of its life. Polish takes time and talent, two things that significantly increase the development costs of an app.

Finally, there's the app store review process. Rejections can mean anything from a few hours of extra development time to rewriting significant portions of the app to killing the fundamental concept of the app and flushing the development costs with nothing to show.

Solution: Consider all Options

Let’s face it, not every idea is best expressed in a native iPhone application. Every app is different, and every situation is different, so what I provide below are two questions to ask yourself before investing in a native iPhone application:

Why target the iPhone?

Is it the popularity of the platform? Device/service features such as the camera, accelerometer, in-app purchases, or push notifications? Is it worth alienating the other mobile markets (or requiring additional concurrent development for other markets)?

Can the same solution be created using a web-based solution?

If the proposed app does not need any of the native-only features such as the camera or accelerometer, and doesn't need an app-store-purchase revenue stream, a mobile web app may provide a better solution and alleviate several of the barriers to entry (app store rejection, developer license, objective-c), and additionally mobile web apps can easily support multiple mobile platforms (droid, blackberry, etc) with little-to-no additional work required. With the increasing support of html5, the gap between that which can be done in a web app and that which requires a native app to do is rapidly closing.

Skeptical? Just have a look at the new html5 YouTube or take it for a spin yourself at m.youtube.com on your iPhone.

Now, clearly there are some apps that would do really well as native iPhone apps, and others that can't be done as a mobile web app. However, a significant portion of apps available on the app store can be readily created as a mobile web app and continue to be just as effective.

Solution, but only half a glass

Want the flexibility and portability of web apps, but be able to tap into the hardware and services only a native app can get? Consider a hybrid app.

Hybrid apps are apps written to run a web app inside of a native app wrapper. It will still require a talented developer and app store approval, but it's possible to reuse much of the app and write similar wrappers for other devices (droid, blackberry, etc).

All of the power, much of the flexibility, and much less of the risk. I expect the hybrid app to only grow in popularity.

Update: Related Article
Craig Hockenberry posted an excellent article on Apps vs. the Web over at A List Apart, in which he more fully explores the benefits and tradeoffs of going native.