What is Xamarin and What Businesses Can Gain By Using It?

What is Xamarin? How has the cross-platform development tool evolved? And what does the ROI look like for teams who decide to leverage it?

As businesses look to reduce costs associated with cross-platform development and keep quality high, Xamarin is an oft-mentioned but little-understood solution. Let’s dive deeper into the world of Xamarin, how it has evolved, and what are its key capabilities. As a bonus, we’ll look at some real-world examples of building an app with Xamarin.

The History of Xamarin

Xamarin first arrived on the scene in 2011, invented by the engineers who created Mono, Mono for Android, and MonoTouch. Mono itself dates back to 2001 as an open-source effort to allow applications built on .NET to run on the Linux operating system.

Since then, the company has raised over $82 million in funding, with $54 million in Series C financing. Investment firms included Floodgate, Ignition Partners, Lead Edge Capital, Insight Venture Partners, and Charles River Ventures.

Now Xamarin operates as a member of the Microsoft portfolio. Since the acquisition, integration between both brands has become even more seamless. In 2016, Microsoft announced Xamarin will be available for every Visual Studio user. That was big.

What Is Xamarin

For those asking this question, it’s not one thing, but many. The Xamarin suite includes several offerings designed for different stages of the development life cycle — from designing and building to testing. 

Here they are broken out by component:

 

• Xamarin.Forms: API used to design an experience across the iOS, Android, and Windows platforms leveraging native controls (Considered by many a cross-platform UI toolkit)
• Xamarin.iOS & Xamarin.Android: Development environments used to build and deploy platform-specific C# code
• Xamarin Test Cloud: As the name implies, a cloud-based application testing platform with the capability to test thousands of devices and automate mobile application testing

Xamarin Studio & Xamarin for Visual Studio: Integrated development environments where the C# code base is written

Actual vs. Perceived Cost Savings Developing with Xamarin

Xamarin has turned heads in the software community with claims of 90% possible code reuse in building iOS, Android, and Windows apps. It’s true. But, realizing the maximum percentage is entirely dependent on the Xamarin offering/approach employed to develop the apps.

Apps can be developed using Xamarin.Forms and Xamarin.Android/Xamarin.iOS. To achieve 90% or higher code reuse, the apps must be built with Xamarin.Forms. Using this approach, the same UX, C# codebase, business logic, and .NET library can be used.

Developing native interfaces with Xamarin.Android/Xamarin.iOS still affords team code reuse (we estimate 30%), because of using the same development language, business logic, and portable class library. Though for cash-strapped or agile-minded organizations, the prospect of redeveloping 70% of an app to release it on a secondary platform is often less than ideal.

Pros and Cons of Xamarin.Forms and Xamarin.iOS/Xamarin.Android

Xamarin.forms

• Can reuse 80-90% of the code
• Code is built in Xamarin Studio or Visual Studio
• Code applies and universally computes across iOS, Android, and Windows mobile platforms
• Data transfer objects (DTOs), business logic, and all user experience assets can be reused
• Built with C# and .NET framework

Xamarin.forms cons

Controls in Xamarin.Forms only support the functionality that is present on all three platforms — functionality is more limited compared to a standalone native app

Choose if: Code sharing and cost savings outweigh the need for UI control

Xamarin.iOS/Xamarin.Android pros

• Can reuse roughly 30% of the code
• Code is built in Xamarin.iOS or Xamarin.Android for Visual Studio
• Developers build multiple platform-specific experiences
• Only data transfer objects and business logic can be reused
• Built with platform-specific C# and .NET framework

Xamarin.iOS/Xamarin.Android cons

Code reuse and cost savings are limited compared to Xamarin.Forms

Choose if: UI and experience can’t be compromised, and there are many specialized experiences

Working with Xamarin.Forms requires a shift in approach and process for developers and designers. Cost savings starts with conceding the control of native development affords. It starts with building the right team.

Building a Xamarin Development Team

There’s no “i” in “team”. But, there is a lot of money. Platform-specific development teams are expensive. Before Xamarin, building a cross-platform app, for example, required developers with Android, iOS, and Windows experience.

Xamarin allows businesses to release an app across multiple platforms with decreased cost and leaner teams, albeit a comparatively deep C# knowledge pool.

The structure of your Xamarin development team will, in part, be determined by the Xamarin approach chosen.

Developing with Xamarin.Android/Xamarin.iOS: Teams choosing to customize the UX for each platform save some labor costs by limiting the development languages. Though, they are still developing the same type of team used to build a native app. Members with platform-specific expertise are needed to interpret the C# code, rebuild the UI, flow, layouts, and apply it to any platform-specific APIs. The project continues to be bound by a “learning curve.”

Developing with Xamarin.Forms: Using Xamarin.Forms, the same developer would be able to build the experience for iOS, Android, and Windows with the same C# codebase, requiring no adjustments. Xamarin.Forms then abstracts that experience automatically. Choosing to build the experience in Xamarin.Forms could save as much as 2.5x cost savings.

Designing with Xamarin.Forms: Many designers are reticent to give up control or aren’t well-versed in the intricacies and limitations of Xamarin.Forms development. Before the experience of a solution can be elevated, teams must invest in understanding the technologies first. Appoint a cross-platform champion on your team or work with one.

Weighing the Xamarin Pros and Cons: Real-World Example

I’ve spent the majority of my time at MentorMate working in the healthcare space. Since biometrics have been top-of-mind, it made sense to use wellness as the inspiration for my build. I created a health dashboard allowing the user to input and track measurements including cholesterol, waist-hip ratio, BMI, and heart rate over time.

Users can view all metrics tracked in the dashboard in a three-by-three grid. They select the desired metric (Ex. cholesterol) that they would like to track. Then the system takes them to another screen.

When the user is looking at the home screen, color signals alert them when they need to update the measurements. Recently entered metrics display as bright green. Over time this color fades to black. Once the metric reaches black, it should be taken again. The dashboard also shows the history of measurements a user took. Future iterations include making this more graphical.

Pro/Con: Building on Android was more user-friendly than iOS.

I began building my Xamarin.Forms app and testing on Android. Bear in mind, this healthcare dashboard was the first piece of technology I (personally) built for Android. My career has been more focused on building in Objective-C for iOS. I installed Visual Studio on my Windows machine and used that to build my project. Since the Android emulators were painfully slow, the path of least resistance was to view work and validate functionality on an actual Android phone. That’s because Windows supports phone debugging only for Android devices.

The process of validating the dashboard on iOS required a little more accommodation, constraining my work environment. While I continued building on my Windows machine, I had to cable the iPhone I used to debug to a Mac (or the build host). Then I connected this Mac to the same Wi-Fi network as my build computer. Why? Visual Studio IDE must reach out to the Mac during certain processes including debugging or designing. The connection between Visual Studio and the Mac OS is made through an SSH connection accessing Apple’s compiler, code signing tools, and certificates.

Minor details separate my experience testing the application on iOS and Android. When debugging on iOS, I was limited to one room as my build host was a desktop. With Android, I was free to roam, and it was faster to debug. I could make updates, then turn around quickly and run it again. That’s why I have opted to do my initial development and testing on Android. Of the Xamarin pros and cons I identified, this was the most meaningful to my work experience.

Pro: Prebuilt Xamarin.Forms layouts offer added functionality.

I built the health dashboard using the pre-defined layouts in Xamarin.Forms using common user interface code. Of the predefined layouts, I used the stack layout with the grid layout nested within. I did this by creating my own layout classes and deriving the functionality I sought. I also built a shared implementation of a “cell” within the grid that is associated with a specific “measurement”, so the majority of the code in the cell (including evaluating the measurement against its limits and determining the color coding) is also reused between the cells.

Essentially, Xamarin.Forms enabled me to write code that says, “Give me a new stack layout in the first cell, and put a grid layout in the second cell.” This process is incredibly intuitive for developers who know how to write and read code. Though as a note, it’s OK to code your layout as long as you understand you must then change your code to change the layout. Unless you have another motive like using a XAML designer, I would stick to coding the screen layouts.

After building out a rough version of the app, imagine my surprise when I fired it up on Android the orientation of the app flipped too. The Xamarin layouts are built and designed to be responsive and fill the screen at the proper resolution. I, myself, did no work to support the orientation change. For teams building with Xamarin, the accumulation of these features saves hours of time. I was even more floored when I got it to run on an iOS device for the first time and it all just worked — everything!

Pro/Con: Work within the design limitations Model-View-ViewModel offers.

While I didn’t work with a designer on my test project, there’s a classic tension that arises between designers and developers. Designers delivering UX/UI that can’t be implemented technically, and developers pushing back and failing to creatively realize the experience. Aligning developers and designers is critical to achieving an elegant UI with Xamarin.Forms.

When designers approach creating a mobile experience with Xamarin.Forms, they must begin by thinking about the common denominator. That’s because they are designing the experience as it will be represented on iOS, Android, and Windows phones. They must ask, “What elements and functionality are consistent across all experiences? How can this be cleanly represented?”

It’s a more disciplined process requiring deep knowledge of interaction patterns across all three operating systems. Design decisions must be based on universal patterns rather than interactions that might delight an Android user and confuse an iOS user.

While I didn’t focus on UX when building my sample app, designing the layout and flow within Xamarin.Forms are where the real benefits of code reuse become clear — up to 80-90%. Though defining some platform-specific behaviorXamarin.Forms with DependencyService is possible.

 

 

 

 

 

 

 

 

Rather than leading with UX/UI, understand the limitations of the platform and craft beautifully within those bounds. Granted, the concessions made to achieve cost savings with Xamarin.Forms will not make or break the experience. It’s much like considering the control of nonresponsive design compared to the slightly less control responsive design affords creative teams. Though (worth noting) if they need more specificity, developers can build a custom renderer.

6 Xamarin.Forms design principles

Spoiler alert, I asked a designer. Here are the best practices to frame experience and aesthetics creation for Xamarin:

1. Strive to create a universal understanding.
2. Study the limitations of each platform.
3. Think across platforms. Just like your development will be.
4. Synthesize first. Design second.
5. Don’t assume functionality across platforms is apples to apples in applying the C# to the SDK.
6. Avoid the temptation to abandon familiar interaction patterns. Why? Xamarin uses native controls where possible so the iOS and Android “text edit” controls look and work like default controls for each respective OS.

Pro/Con: Give your users something to look at while the app loads.

We’ll end with consideration for something that should come at the very beginning — wait time. After completing my dashboard, I noticed it was a little slower to load as it was retrieving results from the server for display. Had I added a graphic or animation that displayed during the load process, the lag may have appeared less noticeable. It’s a minor learning about the Xamarin pros and cons, but every detail counts.