People love the idea of cross-platform development for iOS/Android or try to use a familiar language to develop apps for either or both platforms. There are many solutions and platforms out there and each of them has pros and cons, here we will try to name a few and analyse them: MonoTouch, Appcelerator, RubyMotion, PhoneGap, HTML5, Java2ObjC…
The cons are quite depending on which you choose to go with, but we will analyse them in some aspects: easy for maintenance, native performance, delay for update, community support, pricing/bankrupt, talent hiring…
1. Easy for Maintenance
One thing that most cross-platform framework has problem is that it adds another layer of complexity into your system. If some bug happens or something does not run as intended, you have three times of works. You have to check if the bug is your bug, is your framework’s bug, the interaction between the framework and the iOS/Android platform, and finally, if that is a bug of iOS/Android. Let’s take a simple example:
iOS had an old bug with rotation and I encountered that bug when I tried to use Appcelerator to build my simple project. It took me the whole day to find that bug was an Apple bug, there is a work around in Apple way but that is not well supported by Appcelerator….
2. Native Performance
When it comes to native performance, I can say that most of the third-party frameworks do well in this area. However, HTML5 is not an excel when it comes to this, or at least, not yet. Facebook has shown us an important lesson with its decision to be back to native to improve its performance. I think that in the future, when the WebKit, the hardware and the requirement for a good app has matched each other, more and more apps will be developed using HTML5 and other open web technologies. Simply, because it is open.
So, if you are building something simple and may grow well over a long time, you may consider the hybrid approach to combine HTML5 and native code. This could work well with if you can integrate it with the web service at your backend.
3. Delay for update/community support/pricing
All of them come to the same problem of third-party frameworks, that middle complexity layer that you add into your project. Most of the frameworks will update quite fast when Apple release a new version, except many minor bugs. I used to have code that is working well with Apple in the iOS4 release and stop working when iOS5 is released. The problem gets worse when most iOS5 beta still works well with my apps. So, when I try to run our app on iOS5 final release, I get panic. I don’t know what is wrong with my code, is it the middle framework, is it just Apple’s release has changed something. I finally figure out that Apple has changed some rules in their API and that affects the old way the middle framework is working. I need to wait for their update to get it work.
Most of the middle framework has their premium supports but you either have to pay more or you have to wait a hell long of time. And most of the communities are a fraction of either the iOS/Objc communities or Android communities. At there, at least somebody has worked with your problem, somebody tested and figured a work around.
There are quite a lot of third-party frameworks around, and I am quite sure many of them will go bankrupt or stop working after a while. Or the price can go up, or the support rate gets slow down. You don’t know what the hell is waiting for you there. If your product is very important, be careful, you don’t want to throw tens of thousands of lines of code away and start all over again. These middle frameworks code, unfortunately, are not much reusable. You can generate Objective-C/Java code from them and then continue working from that. But, believe me, reading, understanding and maintaining those generated code are as twice as hard as you write it from the beginning. I don’t say all of them may have problems, but be careful which framework you pick, how long your project will last, and make sure there is a good match. If your project is pretty longer than 3-5 years, maybe thinking deep about it…
5. Talent Hiring
This is a people management, a project management issue. I remember 3 years ago, finding a good iOS developer is as hard as hell. Although it is easier now, it may not make sense to have a whole team of engineers in Ruby/C# and 1 guy in iOS and 1 guy in Android (or 1 guy for both iOS/Android). That means you have to feed 2 more guys, training them with company’s culture, to understand the domain knowledge that you have. And when things grow, each of these 3 teams grows. Another solution is that 1 of the web guy need to learn both iOS and Android development. That’s why it may make sense for you to reuse your team’s talent. It is also a good thing to consider to have a guy with HTML5 to approach the app in hybrid (HTML5+native code) model.