Developers seem to be in two camps these days. There are those who feel native mobile development is the way forward, and those who feel it isn't. This topic has been close to me recently because I was asked to play an advisory role for a mobile project internally. And strangely enough I found myself on both sides of the issue.
So what's the problem with native mobile app development anyway? Over the last year I've built several mobile apps across iPhone/Android/WindowsPhone and I can tell you from experience that maintaining a code base for each platform sucks. It goes against everything great programmers know and love: DRY (do not repeat yourself).
So naturally software developers and vendors started to build tooling that would allow for a single code base. And the idea is spot on. Why write a feature X times when I can write it once and have a compiler build the native code for me? (Or just use html/js/css to build a webapp and tunnel it through the various browsers)
The problem with this wonderful idea is that in practice it never lives up to the hype/promise. And because I couldn't find many objective posts about why to build native I thought I'd take the time to compile a list that I used internally to settle the 'native vs web/hybrid' debate.
Performance
I was reading a great post recently on the 37 signals blog about how they got Basecamp vNext to be so blazing fast. One of the great points made in the post speaks to performance as a feature and I firmly stand behind it.
Speed is one of those core competitive advantages that have long-term staying power. As Jeff Bezos would say, nobody is going to wake up 10 years from now and wish their application was slower. Investments in speed are going to pay dividends forever.
If you have ever used an app built with one of the web/hybrid tools you know what I'm talking about. You click a button and it seems to be less responsive than the native counterpart. You scroll a list view and notice the lag as new items are presented on the page. You transition to another part of the app and you see what looks like frames dropping.
Anyone who thinks performance isn't a feature in the mobile app eco-system isn't part of one. For our sake devices are getting faster with each hardware rev, but clearly native code will always be a step ahead of anything else. (Isn't that why most game development is still done in c/c++)
Consistent User Experience
I downloaded my banks iPhone app recently and the moment I opened it I could tell it wasn't a native app from the look of the buttons and other navigation elements. Turns out they just tunneled their mobile website through a UIWebView so it didn't have any of the usual iOS buttons/date picker/tab navigation/etc. But naturally I thought to myself 'I'm not the average iOS user, so this astetic is surely something only hardcore iOS geeks like myself look for in mobile apps'.
But that illusion vanished recently when I started working with a group of business people to design our companies first mobile app. They not only recognized native iOS and Android components, but asked for them by name/description. One specific example is the UIDatePickerModeDate for iOS. It spoke volumes that normal iOS users loved the native look and feel of controls like this.
It's no secret native controls provide a better user experience but how can you justify writing a code base for each platform? You can justify this because the goal of your mobile app should be to provide a great user experience. Initially this may sound like fluff or something your 'UX guy' might say around the office, but in reality if you aren't the app consumers 'want' to use, they won't use the app at all. Or worse -they will go to a competitor (me and my banking app for example).
Close To The Metal
I was talking with a friend recently who is big into the web/hybrid app ecosystem and he was showing me an issue he ran across with one of these popular frameworks. It was a simple cosmetic bug that didn't effect the functionality of his app in any way, but it bothered him regardless.
Now that issue specifically could be found in the open source code base and fixed because it's javascript or css related. But this did get me thinking about what level of control the web/hybrid solutions offer today. On the iPhone for example you are doing everything inside of a UIWebView. Because you are working on a layer above the native stack you only have so much control over the micro optimizations you are allowed to use when your app needs it for example.
I always find this interesting because one part of me says this is no big deal and you could do any optimization in javascript if needed. But the reality is you are already working in a sandbox and in the case of the iPhone you can only go as fast as the UIWebView will let you. If the complexity of your app starts to grow and you find that you need to optimize something you've already given up a great deal of options because you only have the UIWebView available to work with.
Another great example is when you need access to the platform specific features like location, camera, photos, native maps, gyro, address book, etc. Unfortunately I can't speak about how easy/or hard it is to access these from web/hybrid solutions because I don't have any experience first hand. I can say conceptually these things should be easier to work with from native code because you don't have to work with a generic / lowest common denominator api that may limit platform specific functionality.
At first glance, this may appear to be a minor issue on my list but as I started to think about how applications grow over time I realized the more options you have on a technical level the better. And with mobile apps, native development offers the most control today.
Better online support
When I started building mobile apps the first thing I did was bookmark stackoverflow (as if it wasn't already the defacto). As someone who has spent the last 18 months learning 5 platforms I can tell you from experience that the dedicated people on stackoverflow can really provide a way forward when you get stuck learning a new language or platform.
A simple search for questions about objective-c turns up 72,825 results. The same search for phonegap questions results in 4,184 results. This metric alone makes me want to stick with native app development for the simple fact that it has the most online resources available.
That's not to say other open source tools/vendors won't have great support but from the numbers it's clear the majority of mobile development is done in native code today.
It's an eco-system not just a language
If you want to hear a developer throw something/cry/punch you in the throat just ask them to learn objective-c. The programming language has a bad name in the community that doesn't know much about it. I'm guilty of this myself. Before I even started learning objective-c I was prepared for the worst programming experience known to man.
And I spent a great deal of time learning how to build my first iPhone app, but looking back it wasn't because of objective-c. It was the entire eco-system ...
- Cocoa Touch
- Objective-C
- Xcode
- Interface Builder
- Learning the iOS 3/4/5/vNext apis
- Provisioning DRM to get my app into the store
- How to avoid rejection in the App Store
I would argue that most people who just want to avoid objective-c might find that a great deal of time is spent on the iOS platform/ecosystem and that isn't necessarily something web/hybrid frameworks get you out of completely. Especially if you are using a cross compile (non web) based solution like Mono Touch, you may get to write everything in c# but you still need to learn all the apis / front-end components to build an app.
Learn from my mistakes
When I started my recent project I thought that maintaining 2 or 3 codebases for a single app was nuts. A large part of the reason I feel this way is that on a personal project I was rewriting core domain logic in each app. This wasn't a good idea because any time the business logic changed I found myself in 3 code bases.
Looking back now it's clear I should have abstracted that core logic to some type of REST api so I could avoid rewriting the same code 3x. This way the bulk of the native code I write in each code base is platform specific user experience / like front-end code. The stuff that provides the true value add for mobile in the first place. If you don't need this type of application experience and your business can compete with 'just another app' then maybe native app development isn't the right fit. But for those of us who want to make a run away hit, native app development is the best option today.
