iOS is currently the platform to develop software for. Last week’s acquisition of Instagram by Facebook is an example of a company that, prior to a couple of weeks ago, had only a single entry point to their platform: their iOS app. The entire user base was pushing thousands of pictures per hour through a single application on a single brand of mobile device. Only very recently did Instagram release an app for Android.

That Android release resulted in an additional 10 million new users within 10 days of launch. That’s an incredible number for a small company, much less a tiny company like Instagram.

The number of Android devices in use is what makes it a compelling argument against developing solely for iOS. You can’t walk into a shopping mall without finding a cellular retailer who is giving away an Android device. Naturally, giving away hardware is a great way to push the platform along. Android devices are what make smartphones so ubiquitous today. In January, there were an estimated 250 million Android devices in use.

Rather than argue that startups should focus on iOS, I’d like to move forward with the assumption that both platforms have their merits, and neither appears to be disappearing any time soon. Since both exist, companies are left asking: “Which should we develop for?”

If you’ve worked with a marketing department, you know the answer to that question: “All of them.”

In the last few years, there has been a growing belief that the answer to mobile application development has actually been with us for a while: the web. HTML5 and CSS3 are the revered children of those hoping for a nirvana of application development. Many believe that web apps are the future, and that native applications are merely a relic of the past. By some accounts, it sounds like a great idea. Web-as-mobile apps have some nice benefits:

• No app review – skip Apple’s esoteric review process
• No updates – push new versions live, users receive them on next load
• Iterative development – no updates means small changes can be made quickly
• It runs everywhere there is a web browser

The last item in the list is the real kicker: a magical application that works everywhere. Unfortunately, there are a number of problems with using web technology for apps:

• The internet goes down
• The internet is slow
• Web browsers are slow
• Nobody wants web apps¹²

The way to solve these problems has been clever:³ simply marry the two together. Create a web app, and then wrap a pretty native window around a web viewer. Bundle the result, and ship it to the proper store. The web app can take advantage of local storage (introduced in HTML5), so it’s not even necessary to use a native storage library like Core Data or SQLite.

These apps are impostors: bits of software masquerading as native applications, attempting to deny their true ancestry in the web.

Most people won’t mind, or may not even notice an app is built with web technology instead of native software. The app will look almost identical on all major platforms, which may be a selling point for marketing and branding.

However, iOS and Android have certain UI expectations in place, as set by their respective purveyors. iOS apps look and feel a certain way, and Android apps have their own style. More striking in style are native Windows Phone 7 apps, with their Metro styling. For enthusiastic fans of a particular platform, these design themes are important, because they help unify the experience of using a device.

Apps built outside of native toolkits can quickly reveal their true identity. Widgets looking out of place or choppy scrolling are usually the first signs that something isn’t quite right. After a few minutes, the keen eye will notice things are not as they should be.

Here’s an example I stumbled on this evening: Untappd, a social drinking app that’s been gaining popularity lately.

The main screen in Untappd is fairly typical of a social application. There is a timeline with recent activity is displayed, with a text box for searching, a row of tabs at the bottom (customary for iOS), and a title bar with the app’s branding in it. The first time I launched Untappd, I was greeted with a typical Login / Signup view, which wasn’t particularly startling.

After jumping around a few of the screens, there were a few bits of UI that bothered me: the masking / highlights on the tab bar was all wrong for iOS. You can see the selected tab in Untappd is white, whereas the native UITabBar highlights selected tabs with a blue gradient:

Pull-to-Refresh is an interaction (recently patented) common in many mobile applications, so as I jumped through the views, I attempted to pull a few of them to see if they’d reload. Imagine my surprise to see the title bar sheepishly vacate it’s position at the top of the screen:

After discovering this, I had a pretty good hunch about what was up. I decided to pull the view the other way:

The tab bar seems to wander from it’s southern position as well. These behaviors are common in applications created with PhoneGap, a framework that boasts support for “7 platforms.” I pulled the Untappd.app bundle off my phone to confirm the inner workings of the app:

The presence of PhoneGap.plist, along with a directory named www were enough to convince me of my guess: Untappd is a web app.

I didn’t choose Untappd in particular to pick on it. I’ve only used the app for a few minutes, and it works fine. It definitely doesn’t feel like native apps do on my phone, and I’m left to believe an Android user might say the same thing.

If the goal for Untappd was to ship apps that appear very similar, they have clearly succeeded. The iOS and Android versions appear very similar in form, though seem to leave a bit to be desired in function.

However, if the goal was to ship a polished, buttery smooth⁴ app for iOS, the choice to go with PhoneGap was not the way to get there. Their current offering feels a bit disingenuous, as if the platform wasn’t worth the focused effort.

Clearly, it is.