As an experienced iOS and Android developer, I get a lot of questions about mobile development. Generally this happens at a party or a bar where someone’s friends have chosen to regale me with their plan for “the best app ever.” Fortunately, I talk to serious developers too, and they often ask me what they should use.

Everyone has heard different stories about the fastest, best, and newest way to get an idea out of their head and into an app store. The options seem endless. Native app? Cross-platform solution? HTML5? A mix? Where is a developer to start? What should a growing business invest in? How do we tell the snake oil from the technologies truly capable of propelling us to our rightful place among the app store stars? Like most things in life, it depends.

There are three real options for mobile development: native, HTML5, and cross-platform compiled code. HTML5 is, of course, also cross-platform, but I consider it in a different category from compiled solutions. And those compiled solutions come in every flavor of the rainbow, from JavaScript to C#. Name a language and somewhere, someone is working on a project to compile it into cross-platform applications.

HTML5

HTML5 is hot right now. And what’s not to love? We’ve all heard that it will revolutionize the world. It has a 5. If you haven’t been counting, that’s one more than any HTML yet! Fire up your integrated development environment (IDE) of choice, create an iOS/Android/Windows Phone project, drop in a webkit window, and you have an app. Even better, use a software package to wrap your HTML for you automatically, and start shipping code fast as you can write it. After all, real developers ship code, right?

This approach gets a lot of attention because the promise sounds great: Write your application once and it will run on every browser, operating system, and piece of alien technology imaginable. People will have to start having more babies just to create enough eyeballs to consume it all!

You might have heard of Phonegap, one of the more commonly used tools. It will magically bootstrap your HTML5 Web site with the bare minimum of native code to be able to make it run as an app. But HTML5 still doesn’t provide access to many of the modern device features users want, so solutions like Phonegap tend to also provide some native API hooks to access them, such as cameras, GPS, accelerometers, and other sensors. That’s where we run into the first problem.

The idea goes that you’re going to use a technique called progressive enhancement to build your app as the equivalent of a single seed that can grow into anything from rye grass to a spectacular orchid, depending on the platform the user runs it on. In practice, you tend to end up developing a seed that always grows into rye grass, but sometimes has an odd flower or two protruding from it. Progressive enhancement tends to work fine for individual features, but once you have two, three, or four such cases, the complexity explodes.

Aside from feature access, the other major problem is look and feel. Compared to modern native apps, even the most advanced Web sites still feel flat. HTML5 has really struggled to match the native experience in animation. If you think you’ll work around this, look no further than Facebook.

Last year, Facebook declared that, native be damned, it was letting all its chips ride on an HTML5 solution. Facebook boldly proclaimed that it would defeat the performance and feel problems with a combined approach of money and the sheer force of being Facebook. Fast forward a year later, and Facebook has just gutted and rewritten its iOS app natively. If Facebook can’t make it work perfectly, odds are you can’t either, so this option should be reserved for the type of apps where “good enough” is a reasonable tradeoff for ubiquity.

So if you’re developing a relatively simple app without a lot of graphical flair and have little aspiration of ever taking it to another level, HTML5 may be the path of least resistance. However, you will be working with a very low common denominator, and the results tend to be rather bland when viewed next to native apps.

Cross-Platform Compiled

Maybe you have higher aspirations and HTML5 isn’t quite what you’re after, but it sure would be nice if we could still get an app on two or three of the major stores without writing the thing two or three different times. Enter cross-platform compiled frameworks. The field is still young, but the number of strong options is growing. I can recommend two frameworks, with some reservations: Appcelerator’s Titanium software development kit and Xamarin’s Mono family.

I say “some reservations” because you’ll want to keep some business implications in mind when you’re looking at any of these products. You’re inserting a dependency between yourself and your app. If something goes wrong, or is unsupported, you’re either going to be at the mercy of the vendor’s customer service or have to solve the problem yourself. Remember that these companies are mostly startups themselves.

Another potential issue is that all the platforms I am aware of in this area come with a tradeoff. They tend to have either deep support for one or two main devices, and middling if any support for the rest, or good but incomplete support for many devices. In the first case, you aren’t getting as much return on ubiquity for your investment. In the second case, you may find yourself facing some of the problems with HTML5, where you’re being limited by the feature support or having to write a substantial amount of native code anyway.

I mentioned my reservations. But for 80% of app developers, I would still recommend these products. For beginning app developers, their own track record is a far bigger concern than that of their technology vendors, so there are better things to worry about. You can get a long way using these products. But if you continue to develop, sooner or later you will encounter a problem that requires you to “go native.”

Mono outright demands it, as it’s only designed to build a shared model layer. Titanium provides support for building a shared user interface (UI), but sooner or later you’re going to run into a performance or support issue and have to work around it. Still, for a young startup, that eventual cost may be well worth the huge, immediate benefit of being in multiple stores.

Overall, these tools are a good fit for bare-bones to medium-sized startups with tighter resource constraints. You will get to market faster on more platforms and, depending on your particular product, the results may look nearly native. I would take a look at Titanium if you’re developing an app with modest UI and graphics needs and Mono if you feel like you’re going to need a more custom interface. If they strike your fancy, I would also take a look at apps that use them (they both provide numerous references) and see if you’re okay with the look and feel.

Native

Then there’s pure, uncut native development. You’re going to deal with one vendor, and there are no limits between your imagination and the device’s capabilities. Yet native development comes with one big, fat, obvious downside. You write it, and it works on one platform, and that’s it. That means if you want to add support for another platform, you will be knowingly violating the hallowed developer tenet of DRY (Don’t Repeat Yourself) and starting over from scratch. To ship the same amount of code, you’re going to need almost twice the number of developers, or twice the amount of time. For most companies making their decision today, I wouldn’t recommend this approach.

But there are three cases where I would. The first is apps with high-performance graphics or data processing needs. This includes many games, video applications, and apps that deal with significant amounts of data. Being close to the metal counts in these apps. Or, they need access to places where the cross-platform frameworks simply dare not tread. The second case involves companies that have the resources and aspiration to deliver a cutting-edge mobile experience. And the third would be companies that value complete ownership of their technology stack for IP or other business reasons.

No matter where you fall, remember that there isn’t one “best” tool, only the best tool for the job at hand. If your goal is to build a Formula One racer for a particular platform, then you probably ought to be going native. If you want to get an app out fast, everywhere, take a look at cross-platform compiled options. And if you really, really want your app to run as a Web site too, well, check out HTML5. Whether you take my advice or not, good luck with your projects, and happy apping!