When developing mobile apps, the biggest question is usually, “Which platform first: iPhone, Android or BlackBerry?” If your answer is “All of them,” then maybe an HTML5 mobile web app is for you. Mobile web apps? Really?

Yes, really. But, as you might have expected, it depends on your needs and goals.
When we set out to create our real-time people matching service for professional conferences and events, we began developing it as a mobile web app simply as a means of testing and iterating quickly with the intention to “go native” at a later time.

While we still may do that, we’re in no such hurry at the moment.
Here are some of the questions we asked ourselves when making our decision that you may want to consider.

How will users find our app? How will we get distribution?
If you can optimize your catalog page and maybe even score a highlight on the home page, App Stores are a great way for users to find your app. But what if your app isn’t meant for the general consumer? Does discovery matter?

In our case, we market our app to organizers of professional conferences and events who in turn, tell their attendees about it. Outside of one of these events, our app adds little value to the end user (for now).

With that in mind, we were less concerned about being in an app store or marketplace. Our users need only scan a QR code or type a short URL to access the app.

Do we need to access the smartphone hardware and API’s?
Do you want to use the camera, access the address book, store files in a local library, communicate with other apps, use Apple’s Game Center or gain other system access? If so, then you shouldn’t even consider an HTML5 web app.

In our case, we require limited access to the smartphone hardware and the only API we need at the moment is Location – which works in all modern smartphone browsers. So, for us, the web app wins again here.

OK, that’s not completely true: we use QR codes as a component of our service and scanning one of these codes requires access to the smartphone’s camera. On top of that, we’ve found that general purpose QR code scanners have too many options for the newbie consumer.

To overcome this, we’ve create our own QR code scanner for each key platform that performs one simple function: it scans Qrious codes (only) and opens those encoded URLs in the smartphone’s default browser.

In the future, we’ll likely add in-app notifications to these scanner apps but for now, that’s not necessary. Which brings us to the next question…

How will we send notifications to our users?
We decided to use good ol’ SMS and email. Since our app isn’t native, we can’t take advantage of system alerts on the smartphone. While SMS is more immediate and would generally work fine for our needs, a large portion of our target market uses company-issued BlackBerries – most without SMS.

For these people, we provide notifications using the one feature that the BlackBerry excels at: email.
Of course, there are a host of other questions to be asked:

What about speed? Bandwidth? Local storage? Differences in smartphone interfaces and Human Interface Guidelines (HIG)?
With the ability to store data in the browser cache using HTML5, speed is no more an issue with web apps than with native apps. The bigger issue to consider is that each smartphone application has it’s own standards and guidelines for how apps should appear and function. For now, we decided that our interface would be mostly “iPhone-like”.

In the future, we may do one of two things:
1) Deliver a version of the web app optimized for each device or;
2) Something completely different.

With option two, we’d be designing our own, unique experience, one that doesn’t conform to any smartphone platform. The upside to this approach is that we’re free to explore alternative interfaces that fit the specific needs of our audience and create an interface that doesn’t conflict with the conventions used in native apps.

The downside is that, it doesn’t conform to the conventions of native apps. Some users may be confused by this since it doesn’t “look like their other apps.” Make no mistake, this will take careful planning and much consideration.
Could this approach to user interface work for your app? That’s a post unto itself, better written by a UX professional.

So, what do you think: web app or native app? Tell us in the comments.

John Federico is a digital marketing and business development specialist and co-founder of Qrious. Learn more about him on Twitter at @gadgetboy or his blog at gadgetboy.org.