Quite a bit has been written in the great smartphone native app versus web-app debate. For those of you in the audience who have never read about this great schism, here is the Cliff Notes version. When starting out to create a mobile app, the developer must decide whether to build the application using the native capabilities of the underlying operating system and have the application downloaded onto the device from some marketplace or to create a web app that runs within the mobile operating system’s browser (most likely WebKit). In the case of native apps, you have fine-grain control over the user experience and the full power of the platform’s API. However, you are limited in only providing the app onto the platform you targeted (say iOS). To offer it on another platform (say Android or Blackberry), would require a rewrite of the app against that platform’s API. In the case of web apps, they appear to be stand-alone apps even though they use the browser’s services. By building a web-based app, it is often less expensive, it is cross-platform and the developer is not tied to the requirements of a particular app marketplace. With everything in life, there is a downside and in this case, the user experience may not be as rich as the developer would want or the app maybe unable to take advantage of all of the capabilities of the particular platform.
Obviously, the knight in shining armor that would come to the developer’s rescue would be a cross-compilation framework that would allow the developer to build in one environment natively and be able to cross-compile to multiple platforms (iOS, Android, Windows 7 Mobile, Blackberry). Whether such a framework truly exists and the wisdom of using those frameworks is a matter of great debate. What spawned this particular debate was the recent release of MonoTouch and Mono for Android (formally MonoDroid) and whether these frameworks and others like them would truly allow a developer to reach cross-compilation nirvana. I wanted to share the conclusions of one such debate that recently occurred with members of MobileTwinCities (Richard Monson-Haefel is an author and former Burton Group analyst) that brings this particular issue into focus:
“So you bring up a lot of valid points. I’ll address the one by one:
1. Purity of the native solution
This is an interesting point and I agree with you that choosing a platform because Steve Jobs endorses it or because its some how more “pure” is moronic. Of course we agree because that was never my point. The point was this: With which technology are you going to get the best UX? My argument is that using native development platform for iOS and Android will result in the best UX because you can leverage the native platform without compromise.
2. MVC is Good
Yup. Kind of hard to disagree with this one. In fact, I’ve been saying all along that mobile (at least in the enterprise) is not about the backend. It’s clearly the view technology. My point about bifurcation is this: If you have to write different code for each platform’s view why not write that code in the native platform where you can get 100% leverage of the features of that platform. The model – and to a great extent the controller logic – for any well mobile enterprise application is going to be in the form of services maintained on the backend. So, with a good mobile architecture you are inherently getting MVC. The idea that MonoTouch/MonoDroid somehow aids in the pursuit of MVC is simply not true.
3. Leveraging a Framework they have already invested heavily in:
Well, not much to say about that except that they shouldn’t have invested in it in the first place. I would consider it a sunk cost. A mistake that can be rectified more easily now than later.
The fact is: Using any cross-compiling technology for what is essentially two platforms (iOS and Android) will cost more resources than simply developing native clients for both. The cost is not immediate and obvious which makes it more difficult to see but having been around for a while and seen this strategy attempted many times I can tell you that it doesn’t benefit anyone but the vendor selling the cross-compiling technology.
4. Immediate benefits of cross-compiling solutions
Well, I would say that the benefit is imagined. Yes you can develop very simplistic applications with cross-compiling tools but try to do something a bit more sophisticated and the benefits of cross compilation is outweighed by the benefits of native development. Why this is surprising for anyone whose been around for a while is a total mystery to me. It’s been demonstrated many times in many areas in the past.
5. 3rd Party vendors introduce more risk is a fallacy.
Well, I guess I would bet on Google Android surviving a challenge from Oracle over a small 3rd party cross-compiling vendor surviving the next five years. Wouldn’t you?
As far as convincing a CIO or CEO to invest in native development its simply a matter of talking about the facts. These guys didn’t become CIO’s and CEOs by accident -they are smart. They may have been convinced that cross-compiling is the way to go in the absence of an intelligent argument in favor of native development, but presented with a well executed argument in favor of native development its hard to see why a CIO or CEO would choose a cross-compiling solution from a fly-by-night vendor. “
I did not want to try to paraphrase the entire stream of conversation, I would encourage you to read the entire conversation here:
http://www.linkedin.com/groupItem?view=&gid=1821682&type=member&item=49467897&qid=eb18591e-8362-46d3-8342-046b997c217a&goback=%2Egmp_1821682
Cross Compilation vs. Mobile Native Development Debate
by Perry Hoekstra on April 20th, 2011 | ~ minute read
