Overview
As reported by Tim Anderson
Cross-platform development is a big deal, and will continue to be so until a day comes when everyone uses the same platform. Android?
HTML? WebKit? iOS? Windows? Xamarin? Titanum? PhoneGap? Corona? ecc.Sometimes I hear it said that there are essentially two approaches
to cross-platform mobile apps. You can either use an embedded
browser control and write a web app wrapped as a native app, as
in Adobe PhoneGap/Cordova or the similar approach taken by Sencha, or
you can use a cross-platform tool that creates native
apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero
FireMonkey.Within the second category though, there is diversity. In particular,
they vary concerning the extent to which they abstract the user
interface.Here is the trade-off. If you design your cross-platform framework you
can have your application work almost the same way on every platform.
If you are sharing the UI design across all platforms, it is hard to
make your design feel equally right in all cases. It might be better
to take the approach adopted by most games, using a design that is
distinctive to your app and make a virtue of its consistency across
platforms, even though it does not have the native look and feel on
any platform.
edit Xamarin v3 in 2014 started offering choice of Xamarin.Forms as well as pure native that still follows the philosophy mentioned here (took liberty of inline edit because such a great answer)
Xamarin Studio on the other hand makes no attempt to provide a shared GUI framework:
We don’t try to provide a user interface abstraction layer that works
across all the platforms. We think that’s a bad approach that leads to
lowest common denominator user interfaces. (Nat Friedman to Tim Anderson)
This is right; but the downside is the effort involved in maintaining two or more user interface designs for your app.
Comparison about PhoneGap and Titanium it’s well reported in Kevin Whinnery blog.
PhoneGap
The purpose of PhoneGap is to allow HTML-based web applications to
be deployed and installed as native applications. PhoneGap web
applications are wrapped in a native application shell, and can be
installed via the native app stores for multiple platforms.
Additionally, PhoneGap strives to provide a common native API set
which is typically unavailable to web applications, such as basic
camera access, device contacts, and sensors not already exposed in the
browser.To develop PhoneGap applications, developers will create HTML, CSS,
and JavaScript files in a local directory, much like developing a
static website. Approaching native-quality UI performance in the
browser is a non-trivial task – Sencha employs a large team of web
programming experts dedicated full-time to solving this problem. Even
so, on most platforms, in most browsers today, reaching
native-quality UI performance and responsiveness is simply not possible, even with a framework as advanced as Sencha Touch. Is the
browser already “good enough” though? It depends on your requirements
and sensibilities, but it is unquestionably less good than native UI.
Sometimes much worse, depending on the browser.
PhoneGap is not as truly cross-platform as one might believe, not all features are equally supported on all platforms.
-
Javascript is not an application scale programming language, too many global scope interactions, different libraries don’t often co-exist nicely. We spent many hours trying to get knockout.js and jQuery.mobile play well together, and we still have problems.
-
Fragmented landscape for frameworks and libraries. Too many choices, and too many are not mature enough.
-
Strangely enough, for the needs of our app, decent performance could be achieved (not with jQuery.Mobile, though). We tried jqMobi (not very mature, but fast).
-
Very limited capability for interaction with other apps or cdevice capabilities, and this would not be cross-platform anyway, as there aren’t any standards in HTML5 except for a few, like geolocation, camera and local databases.
Appcelerator Titanium
The goal of Titanium Mobile is to provide a high level, cross-platform JavaScript runtime and API for mobile development (today we support iOS, Android and Windows Phone. Titanium actually has more in common with MacRuby/Hot Cocoa, PHP, or node.js than it does with PhoneGap, Adobe AIR, Corona, or Rhomobile. Titanium is built on two assertions about mobile development:
– There is a core of mobile development APIs which can be normalized across platforms. These areas should be targeted for code reuse.
– There are platform-specific APIs, UI conventions, and features which developers should incorporate when developing for that platform. Platform-specific code should exist for these use cases to provide the best possible experience.
So for those reasons, Titanium is not an attempt at “write once, run everywhere”. Same as Xamarin.
Titanium are going to do a further step in the direction similar to that of Xamarin. In practice, they will do two layers of different depths: the layer Titanium (in JS), which gives you a bee JS-of-Titanium. If you want to go more low-level, have created an additional layer (called Hyperloop), where (always with JS) to call you back directly to native APIs of SO
Xamarin (+ MVVMCross)
Xamarin (originally a division of Novell) in the last 18 months has
brought to market its own IDE and snap-in for Visual Studio. The
underlining premise of Mono is to create disparate mobile applications
using C# while maintaining native UI development strategies.In addition to creating a visual design platform to develop native
applications, they have integrated testing suites, incorporated native
library support and a Nuget style component store. Recently they
provided iOS visual design through their IDE freeing the developer
from opening XCode. In Visual Studio all three platforms are now
supported and a cloud testing suite is on the horizon.From the get go, Xamarin has provided a rich Android visual design
experience. I have yet to download or open Eclipse or any other IDE
besides Xamarin. What is truly amazing is that I am able to use LINQ
to work with collections as well as create custom delegates and events
that free me from objective-C and Java limitations. Many of the
libraries I have been spoiled with, like Newtonsoft JSON.Net, work
perfectly in all three environments.
In my opinion there are several HUGE advantages including
- native performance
- easier to read code (IMO)
- testability
- shared code between client and server
- support (although Xam could do better on bugzilla)
Upgrade for me is use Xamarin and MVVMCross combined. It’s still quite a new framework, but it’s born from experience of several other frameworks (such as MvvmLight and monocross) and it’s now been used in at several released cross platform projects.
Conclusion
My choice after knowing all these framwework, was to select development tool based on product needs. In general, however if you start to use a tool with which you feel comfortable (even if it requires a higher initial overhead) after you’ll use it forever.
I chose Xamarin + MVVMCross and I must say to be happy with this choice.
I’m not afraid of approach Native SDK for software updates or seeing limited functionality of a system or the most trivial thing a feature graphics. Write code fairly structured (DDD + SOA) is very useful to have a core project shared with native C# views implementation.
References and links
- http://www.theregister.co.uk/Print/2013/02/25/cross_platform_abstraction/
- http://kevinwhinnery.com/post/22764624253/comparing-titanium-and-phonegap
- http://forums.xamarin.com/discussion/1003/your-opinion-about-several-crossplatform-frameworks#Comment_3334
- http://azdevelop.azurewebsites.net/?page_id=181
- https://github.com/MvvmCross/MvvmCross
- http://pierceboggan.com/post/51671827932/binding-third-party-objective-c-libraries-in