You have to be living under a rock to miss the shift in Web usage from “traditional” devices (desktop and laptop) to mobile devices (phones and tablets). For example, in India, mobile phones now account for nearly 50% of consumer Internet usage, and mobile usage is growing rapidly world-wide.
As Web site operators watch mobile usage grow, the next thought is usually: “let’s build a mobile app!” It’s a good instinct, but I think it’s also a great way to waste a lot of time and money. Leaping in without any insight on mobile usage is a good way to build the wrong app. Also, it’s easy to end up with something that only partially replicates Web site functionality, frustrating users and creating two different UIs to maintain in parallel.
For a better strategy, Facebook is a good example to study. They took way too long to focus on mobile, but their sequencing is a good place to start. (Note: this advice is really for existing Web sites).
Following their example, here’s a “starter” mobile plan:
Step #1: Mobile-enable your Web site. Remember m.facebook.com? You can get pretty far these days with just HTML5. Use your mobile usage data to figure out what areas to prioritize (Google Analytics will break out mobile usage). Consider both tablet and phone cases: depending on your application, you may want to deal with them separately.
Step #2: Develop a native app, with generous use of embedded browser widgets. Consider which app elements must to be native for the best experience, and do the rest using embedded browser widgets (e.g. WebKit). Most of your app will actually be HTML5 served from your servers, and you can change content on the fly without having to do an approval cycle with Apple (which can take weeks).
You should be able to leverage the HTML5 work you did in step 1. Use your existing mobile usage data to prioritize Android vs iPhone and phone vs tablet.
Step #3: Go 100% native. (If needed) At this point, you should have a good sense of the most important use cases, platforms, and form factors.
Edit to taste!