Going Native

When Rick and I started Big Swing, we decided to focus primarily on developing native iOS apps. Like many developers new to iOS, I had checked out many of the cross-platform alternatives, or as Rick likes to say, "I did everything I could NOT to learn iOS." But I quickly saw the limitations of these solutions and jumped into Cocoa head-first.

It's a big decision, and one we've had to defend quite often. We've been asked by many clients about building cross-platform apps. What an alluring concept: save time(!), save money(!), double or triple your customers(!). If your app is simple and doesn't really need full integration with the hardware, mobile web may be the way to go.

But we've talked to a few teams who have tried going cross-platform and either ending up with a compromised product or needing to start over from scratch with native tools. Even Facebook and LinkedIn, two of the largest, staunchest supporters of mobile web, changed their tunes and released native iOS versions of their apps.

So why go native? First, even though mobile devices are getting more powerful every year, they're still a far cry from laptops and desktops. You need every ounce of performance you can get out of mobile devices. Apple gives you very powerful classes and APIs to access this power (as does Google and Microsoft for their ecosystems).

When you use third-party tools, you're one or two steps removed from the platform itself. You rely on a third party's decision on how to enable any kind of functionality, and how polished and tested their decisions actually are. This can really limit your choices when things aren't working well, or just not working.

Second, although the "write-once-run-anywhere" motto of mobile web is alluring, it's easier said than done. Even with a code base that uses open HTML5 or JavaScript, you'll  need a large development and QA effort to make sure everything runs consistently on all supported platforms.

Beyond that, iOS, Android and Windows are entirely different platforms, and their users  want their apps to maintain a consistency with on another. Throw in an app that was designed primary for the iPhone, and an Android user will find the experience lackluster or confusing.

So is that the final answer? Definitely not. The tools and tech are still evolving, and some pretty smart people are figuring out really cool things to do with mobile web. Even Rick and I are hard at work on some projects that make heavy use of HTML5.

But for now, if you're planning to make an app that is more than a web site in your pocket, native is still the way to go. As Facebook stated in their native iOS announcement, "Building on native iOS gives us a major opportunity to keep making the app faster, more reliable and feature-rich."