If you’re building software today, you’ve probably faced the question of whether or not you need to build a mobile version of your application. In that case, or in the case where you’re decided from the outset you’re building a mobile app, the next question is, which mobile platform do you target? Here there are several options:

• Target Android. It’s got the biggest market share. (69% in 2012)

• Target iOS. It’s where the money is (iOS apps earn over 2x as much as Android for paid downloads and In-App Purchases).

• Target Windows Phone 8. Its Nokia phones are gaining in popularity (sales doubled from Q3 2012 to Q3 2013), but it’s still a small player (4% globally).

• Target all of the above:

  • Build a responsive, mobile-optimized web site
  • Build a hybrid mobile application using HTML5/JS running on the mobile device
  • Build separate native applications for each platform

Of course there are many valid reasons for building native apps. If there are unique device capabilities that you cannot utilize otherwise, naturally write native code. If you only need it to run on one device and your team knows that platform, write native code. However, if you’re going for maximum reach, then you’re going to want something that runs on all phones. That means you’re either going to have to write at least the UI layer multiple times (even using something like Xamarin, which requires separate code for iOS and Android), or you’re going to want to embrace web-powered options.

Building a mobile-enhanced web application is of course still a viable option. However, this limits you to running in the browser, and although there are tricks that can be used to remove the browser chrome or have the bookmarked web page appear like an app on the device, the page is still not going to show up in the app store, and thus won’t benefit from the discoverability this provides. Web sites also cannot take advantage of many device capabilities that native or hybrid applications can, which of course can also be a showstopper.

So what about Hybrid Mobile Applications?

These would seem like the no-brainer solution. They’re built like web pages, but are packaged up and deployed to the device as an actual app. They’re sold in the app store, and in most cases they’re indistinguishable from native apps. However, some notable companies have thrown HTML5-based apps under the bus, claiming they were the root cause of problems the app had. These claims were quickly proved bogus, in this case via a copy of Facebook’s app built using HTML5 by developers who actually knew what they were doing. Remember, developers can build slow, buggy crap on any platform – that’s not the platform’s fault.

It will always be possible to achieve faster performance using native code than using something that sits above native code. This is true on your desktop computer and on your web server. Well-tuned native C++ code is going to run faster than C# code running in the CLR. The thing to remember is that performance is only one consideration for your application, and that premature optimization is the root of all software evil. If your application can achieve “good enough” performance using an abstraction layer that makes you more productive, and this means you can release your software sooner, with fewer bugs, for less cost, then that’s probably a reasonable way to go. Remember when considering optimizations, going beyond “good enough” is waste in most cases.

The other thing to remember is that Moore’s Law still applies. Yes, mobile devices have more limited computing power than their desktop forefathers, but these devices’ capabilities are increasing dramatically and constantly. What’s more, the operating systems and Javascript engines that run on these devices are also being improved rapidly. That means any perceivable difference in performance between well-written native and hybrid applications is rapidly vanishing, and with it the advantage of writing native code for every platform “because performance.”