Cross-Platform Technologies: The Destructive Compromise.

The engineer in me loves looking for efficiencies. So when after the first 1.0 version of Lobaco was good enough for me to call it “done” (in the sense that the feature set for it was frozen) I started thinking about the best way in which to tackle the mobile platform which I believe will be the key in achieving the goals I set out for it. I had pretty much resigned myself to go for the iPhone first as it seems to be the best place to target for early adopter types and figured the Android version could come once Lobaco gained some traction. Still the lure of being able to develop the application once and deploy it across multiple handsets in one go made the engineer in me jump up and down with delight, leaving me little choice but to explore my options.

Long time readers will know that my most recent attempt at cross platform development came the way of Sencha and 2 weeks misplaced effort in trying to get it to work. The library itself is quite comprehensive and does a good job of emulating many of the native functions that you’d expect to see on a native iPhone application. However the problem is that performance wise it’s a total dog and would require me to undergo yet another few weeks in building a fundamental base in order to achieve the same level of productivity that I had just gained with the iPhone. Whilst I’ll still have to undergo a similar amount of effort in order to learn how to program for Android I know that the eventual application that comes out of the end of that process will be much better and worth the time invested in it.

However this wasn’t my first foray into the world of cross platform development. Way back in the beginning, long before I actually got a Macbook and Xcode, I started doing preliminary research into cross platform libraries. After getting thoroughly confused with a few code examples in Objective-C a friend suggested that I have a look at the MonoTouch framework which would allow me to leverage my existing C# skills on the iPhone. The problem there wasn’t so much the language as the paradigm I was operating under and whilst using C# might’ve helped to ease me into it without a fundamental understanding of how things work on the iPhone I would’ve gone through just as much trouble in order to use that framework, without the benefits of coding natively. Not to mention being out $100 for the pleasure and still having to buy a Mac device in order to be able to use it.

The problem I find with many cross platform technologies is that they have the unfortunate problem of making compromises when it comes to conflicts between platforms. Sencha, for all its goodness, has decided to look like an iPhone application. This is great, on the iPhone, but for any other device it’s going to be a drastic shift away from the experience the user is expecting. Even cross platform libraries that generate native code will still suffer from destructive compromises because of the different ways in which the major smartphone OSs go about their tasks. Thus you either constrain yourself with limited functionality or you have to cater for those special usage type scenarios, negating the power of the framework you’re using. Cross platform libraries are fantastic in some use cases, but their applicability is really quite limited.

If you’re looking to target multiple platforms I still believe it’s best to go for the native option, even if the development investment will be much higher. Realistically choosing a single platform to begin with isn’t a bad idea with both Android and iPhone (although Android is probably your best bet) being quite viable to test if the market will respond well to an idea. If your idea has legs then you can take the time to invest in some of the other platforms, delivering a much better end user experience. Cross platform technologies might work for some ideas but unless you’re doing nothing above the rudimentary you’re much better served by going native.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.