Skip to content

How to develop cross-platform mobile apps faster?


Apr 9, 2015 - 7 minute read

Template Blog
Rafał Świerkot
I'm a mobile application developer with solid experience in Android platform.
See all Rafał's posts

HC NHS Survey Blog Ad



We as a Mobile Team are constantly thinking of how we could deliver more value to our Customers within the same budget and recently we have faced a challenge of not being able to provide a 24/7 support for native applications partially developed by us.

Applications were available on three platforms: Android, iOS and Windows Phone. The real problem was platform-specific knowledge required to support each version. Existing approach needed three developers to fully support the application. With a small team (3-5 people) you cannot provide the required level of coverage. It is also not cost effective. That is why we turned our eyes towards frameworks for developing hybrid applications.

Xamarin at a glance

Among many available solutions, there was one particularly interesting - Xamarin. In this particular case it seemed like a silver bullet. First of all, generated applications are fully native. Secondly, platform specific knowledge needed to develop and maintain applications in this framework is limited to minimum. Additionally, the whole team can work on a single product (never underestimate synergy). From our company perspective another advantage of Xamarin is that it is based on .NET and C# - the framework and language we widely use and are experts in. There are two main approaches to develop applications in Xamarin - "Forms" and "3+1". Concepts are depicted on the diagram below (please take a moment and appreciate an extraordinary "MS Paint" skills of our Business Analyst):Xamarin Forms

Xamarin Forms

Xamarin 3+1 Xamarin 3+1


The idea behind Xamarin Forms is to implement business logic as well as the user interface as a common code shared among all three platforms. The second approach, 3+1 (also called classic), is to implement application logic as a shared code, but keep the native way of handling user interface.

Case Study

The most efficient way to learn a new technology is to start using it, so we prepared a backlog for simple application to test both approaches. It was a typical master-detail view application with map, local storage, push notifications and integration with RESTful API. Additionally, we wanted to provide support for both, smartphone and tablet layouts. We wanted to avoid comparing apples to oranges. Therefore functionality was meticulously chosen so that when the research is done we have something that is actually comparable against native effort.

Share factor for our sample application was about 50%, which means that half of the code was shared among platforms. [Xamarin 3+1]

Xamarin Forms

In this approach, Xamarin promises a lot i.e. "write once, run everywhere". It is important to note here that we share our own experiences. It is possible that this personal view would be different if we had more time for investigation.


The indisputable advantages are definitely:

  • flexible programming language (C# with its syntactic sugar like lambdas),
  • plenty of Dependency Injection libraries to choose from
  • and support for Reactive programming.

Another significant thing is a share factor, which in this case was over 90% (of code reusability level on all platforms). On the other hand, there were a few glitches that had negative impact on development time like: inadequate error messages or rare compiler errors (e.g. initialization list on Android was compiling fine, but it failed at runtime on iOS). We could not resist a feeling that these tools were still under development, for example intelli-sense was not working for items defined in auto-generated partial classes. Additionally, Xamarin's community is not thriving and performance of SQLite database seems to be low. What was also particularly annoying, especially for someone who have earlier used intellij IDE, were issues with project files. Once we had problems with image resources that were not loaded properly in Windows Phone project. It suddenly stopped working, without any noticeable reason.


Our list was a typical dynamic list with unknown number of items. At the beginning it seemed like nothing particularly difficult, but the devil as always is in the details.

Relative Layout to manage widgets of the single item displayed within dynamic list. "Why would you bother?" you may ask yourself. Well, on Android, layout managers (Linear, Frame, Relative) are quite heavy in comparison to simple widgets (Text, Image, Spinner, etc.). In most cases, single relative layout used in the right way might reduce total number of used layout managers to achieve better performance and lower memory footprint. Additionally, relative manager is helpful in defining resolution- and density-agnostic layouts. This can be crucial if you plan to support multiple devices with a single codebase.

Another problem was views' reuse for list items. In Android, you can implement your list in such a way, that the view used for displaying row item which is going off the screen, can be reused for the next item that will appear when you scroll the list. This optimisation addresses problem of inflating the layout, a time consuming operation. In Xamarin Forms, we did not find a support for such feature and efficient layout is very important when you want your list to scroll smoothly.


For the details screen the relative layout mentioned earlier was working just fine with static layouts, so it was possible to achieve the optimum layout definition. The only thing that was exceptionally annoying was the lack of graphical layout designer. You have to design layouts in XML files manually and run the application to see the results. This can be very time consuming for complex layouts.


Displayed maps are have nice, native look & feel. Standard gestures, typical to a particular platform, work as expected (e.g. on Android platform it is possible to zoom in and out with single finger by double tapping and swiping).

A very positive first experience was unfortunately revised after checking support for map interactions. Have you seen an application which sole purpose was just to display the map? In most cases your expectations are a bit higher. Typically, map view consists of pins, overlays, balloon messages and other elements that user can interact with. It turned out that there is no "Pin Selected" event. Lack of such basic feature is really disappointing. I know it can be implemented manually, but the point is that it is not available out-of-box. Since we consider Xamarin as a way to reduce the development time, this becomes an issue.

The list was scrolling lightning fast [Xamarin 3+1]

Xamarin 3+1

In this approach, business logic is a common code shared (as previously), however the user interface is defined separately for each platform.


The overall feeling of 3+1 concept was very positive. We had an opportunity to dive deeper into the platform and we found no blockers whatsoever. It looks that Xamarin works hard to provide  wrappers for most recent native libraries to developers.

Share factor for our sample application was about 50%, which means that half of the code was shared among platforms. It was even better when we added support for tablets. Most of UI excerpts prepared for smartphones could be easily reused in tablet layouts without any changes - synchronization between list and map worked out-of-the-box thanks to MVVM. Same for different device configurations. UI fragments defined for landscape layout could be easily reused for portrait orientation. Strangely, database performance issues mentioned earlier were not observed with 3+1 approach.

On the downside, development tools are not as efficient as native equivalents. There are plenty of IDE features missing, which makes native development a walk in the park (e.g. labelled bookmarks, intelli-sense for resources, displaying values of resources directly in the source code - strings, colours, and many, many others). Xamarin combines together different toolsets, UI/UX models and different execution models, however, we should not expect that everything native developer is used to will be available in Visual Studio.


As Xamarin provides wrappers for most recent native libraries, problems described in Xamarin Forms simply disappeared. We used the Recycler view and there were no limitations on how to define the layout for a single item. Needless to say, the list was scrolling lightning fast.


Similarly to list, no problems here. Graphical designer was available and very helpful. For those demanding UI developers, there is also a possibility to use native tools to define the layout.


Just as in Xamarin Forms, maps had native look & feel. This time Xamarin provided fully functional map wrappers (i.e. no problems with supported events). All the features available in native platforms were also available here, but please note that as each platform supports maps differently, the code share factor was a bit lower.

The knowledge gap between implementing efficient application in Xamarin and, for example, Android is very low. [Xamarin 3+1]


Xamarin Forms in our view can only be recommended for projects with simple UI and complicated business logic. It might be difficult to develop efficient application with complex user interface, because of missing support for dynamic layouts. Therefore, Xamarin 3+1 is our default and recommended option.

Share factor achieved with Xamarin 3+1 was about 50%. The development time for all three platforms was reduced by 1/3 in comparison to native. Undoubtedly this factor will vary depending on the application feature set, but overall the decrease in development time was significant.

Team skillset necessary to develop applications for Android, iOS and Windows Phone with Xamarin is definitely lower. Platform specific knowledge is still very welcomed, but as mentioned before, it is reduced to minimum. Another important thing is that Xamarin lets you leverage your experience with native development. The knowledge gap between implementing efficient application in Xamarin and, for example, Android is very low.

Finally, pricing: To develop applications for all three platform you need at least 1 license for iOS and 1 for Android. Support for Windows is free. Cost for one year business license is $999.

Next steps

Please keep in mind that our research is not done yet, and since the hybrids world is constantly evolving we are very aware of the amount of work ahead of us. As far as Xamarin is concerned, we still plan to investigate notifications and support for Windows platform.

Stay tuned and if you would like to discuss further the hybrids please come in. Our doors are always open (room 3.48) :-)

HC NHS Survey Blog Ad
Rafał Świerkot
I'm a mobile application developer with solid experience in Android platform.
See all Rafał's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.