What we learned from using Xamarin.Forms

According to Xamarin using Xamarin.Forms can increase code-reuse for Android, iOS and Windows from 70% to 90%. 


  • Number of available controls is still limited. Some supported controls are missing critical properties. For example, Picker is missing bindable.
  • Some XAML features are missing while others are implemented differently.
  • Documentation is often insufficient, sometimes limited to a list of properties and method signatures.


  • Missing controls can sometimes be substituted with third-party plugins.
  • XAML allows specifying platform specific layouts with OnPlatform and OnIdiom.
  • Elegant publisher-subscriber implementation allows loose coupling between platform specific and shared code.

Crossplatform Mobile App development with Xamarin

Now that Microsoft put its’ weight behind cross-platform C# development for Android and iOS with Visual Studio 2015, it makes even more sense to take a look at Xamarin.

Xamarin interacts with iOS and Android platforms via proxy libraries MonoTouch and Mono.Android.


  • Crossplatform – Multiplatform support is provided by standard Mono/.NET libraries – System.Data, System.IO, System.Net etc.
  • Xamarin apps run Android, iOS and Windows.
  • Visual Interface Designer- InterfaceBuilder and Visual Studio add-on allow visually designing UI.
  • C# – Developers familiar with C# can build apps suitable for AppStore distribution without having to learn Objective-C or Java.


  • Memory Leaks – Most classes implement IDisposable interface and memory leaks are a serious concern. Elements are often proxies to native objects and Dispose it required to memory leakage.
  • Exceptions – While Xamarin throws exceptions such by raising MonoTouch.Foundation.MonoTouchException and Java.Lang.Throwable, yet some exceptions only happen inside framework and never get to the app. Stack overflow, for example, crashes the app without even raising any exceptions.
  • Some native API calls are not supported. For example, MonoTouch.AddressBook.ABPerson.GetVCards is missing. Xamarin.Android does not generate events AnimationStart and AnimationEnd for ViewFlipper.
  • Support – there is a lot more information and help available for native development.

The shortcomings of Xamarin are manageable, but in some instances developers have to be ready to hack the Xamarin platform or engage a consultant to help with topical issues.
If you are planning to develop an app for just one platform, it probably makes sense to stay native, even if it requires learning a new platform.

Crossplatform Mobile App development with Appcelerator Titanium

We would like to share lessons with learned from our experience developing mobile apps with Appcelerator Titanium. This information might be helpful to anyone selecting development tools for a new mobile app.


  • JavaScript – an ability to code in JavaScript then run an app on multiple platforms including Apple iOS and Google Android allows developers familiar with web technologies to develop apps without having to learn native iOS and Android programming languages and tools.
  • Rapid development – prototypes can be developed quickly with little code in JavaScript.
  • Same sources work on multiple platforms – the same Titanium JavaScript code, with little optional minimal variants, runs on multiple mobile platforms including: iOS, Android, Blackberry and now Windows.
  • Community – large developer community with active forums and a marketplace with a multitude of modules extending built-in functionality.


  • Double-clicking – An app developed on a native platform normally disables the element that generated an event while one is being processed. For example, a user presses on a button and while the app does what is necessary, the button becomes greyed. Appcelerator Titanium can send multiple events, which may be undesirable. Think of a user sending the same chat text multiple times.
  • Android memory management – Android memory management is a challenge even for native apps. An app will often receive only 16 MB of memory. Since each pixel is represented by four (4) bytes, one picture full-screen image with a resolution of 480×800 will take 1.5 MB. Given this reality, developers commonly have to monitor activity service for resource availability and exceptions to prevent apps from exhausting memory. Titanium does not provide this information to the app, and there is no simple way of getting it. In addition, Titanium has problems with memory leaks, which can be mitigated to a degree.
  • Conditional code for each platform – both API and screen resolutions require that developers create a variable or a function set to the platform and constantly include lines similar to the below:

    if(‘iPhone’) >= 0)
        isIPhone = true;
        isAndroid = false;


   var fontSize = hookup_utils.isAndroid() ? “6pt” : “10pt”;


    if (hookup_utils.isAndroid()) {
        winParam.exitOnClose = true;

  • Lag behind native tools – Apple releases RC versions several months to releasing the OS to the end-users. This allows developers using native tools to submit apps for an approval in time for general availability. Titanium lags few months behind native tools and usually these no way to coordinate release with Apple. Depending on the marketing strategy, this can seriously impair your ability to piggy-back off Apple marketing campaign.
  • Bugs – Each Titanium release addresses some of the known bugs, yet comes with its’ own set of new problems. Since Appcelerator sits above the native platform, all of these bugs are in addition to iOS and Android bugs. For example, Titanium version 3.1.3 caused a significant regression with animations.


The above problems are solvable. Depending on technical requirements and developers’ experience, Titanium can be a great platform. The important part is to make an educated decision so that benefits clearly outweigh challenges.