Click here to Skip to main content
13,198,322 members (54,136 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


8 bookmarked
Posted 17 Dec 2015

Xamarin: 5 Reasons I'd Do It Again In a Heartbeat

, 17 Dec 2015
Rate this:
Please Sign up or sign in to vote.
Xamarin: 5 reasons I'd do it again in a heartbeat

Pretty darn nice. That about sums up how I feel regarding Xamarin development after working with it for the last six months. I'd choose it again in a heartbeat despite having built pure native apps for every major platform and having plenty of experience building mobile friendly websites with JavaScript. Here's why:

1. Xamarin Forms

Don't listen to the detractors. When our team started, I heeded the rumors that Xamarin Forms isn't ready for anything more than settings pages. We heeded the advice and started with mostly MvvmCross and Interface Builder story boards.

But the more Xamarin Forms pages we built, the more we loved it. We eventually went back and replaced every single platform specific UI page with a cross-platform Xamarin Forms version that rendered fully native controls. The two-way databinding, native support for the MVVM design pattern, and easy to understand (for me) XAML were just icing on the cake.

It wasn't perfect. We occasionally ran into hiccups with controls that failed to offer the UI customization we wanted. But once we mastered Custom Renderers, we were able to accomplish pretty much anything UI-wise. Animations, completely custom pages, and dynamic rendered controls, all quite doable once you're up to speed.

With Xamarin Forms, we got a fully native look and feel for our app while achieving 76.3% code reuse (most of which was the important stuff), plus an easy out if the abstraction failed us. Fantastic.

2. Code Sharing

Not what you're thinking. Sharing code between iOS and Android is obvious. We used Portable Class Libraries to share code between our iOS and Android and our server-side web application.

For one thing, sharing our models was huge. That made strongly typed json serialization/deserialization a breeze. But it got even better with the "free unit tests" our compiler gave us. Rename a field on mobile? Zing: immediate compilation error server-side. Nice.

Once we got in the swing of things, we started sharing enums between Entity Framework ORM and database on the server-side, the cross platform models, our SQLite database, and our mobile code. Then we started sharing utility methods, validation, and even miscellaneous code like cryptography. Yes, the crazy-smart folks at Xamarin even ported the .NET Framework's cryptography libraries to iOS and Android, thus allowing the exact same logic for encryption/decryption everywhere, how cool is that!

While we used TypeScript for the web front-end, I suppose one could extend code sharing absolutely everywhere by using Script Sharp. That would be pretty insane.

3. C#

C# is a dream. I'm probably biased, but to me, the language is downright beautiful. There's Expression Trees, a feature I have yet to see in any other language. And LINQ is amazing. But async/await takes the cake. It's the prettiest technique I've ever seen for freeing up the UI thread in mobile or desktop apps or releasing your web server's thread to handle other requests all while keeping your code readable. Async/await is arguably worth Xamarin's price of admission.

var animation1 = AnimateLayout(CategoryAttributes);

var animation2 = AnimateLayout(TemplateAttributes);

await Task.WhenAll(animation1, animation2);

// ui thread is free. FREE! FREE!!!!
DoStuffAfterAnimations(); 	// <- *UI thread* picks back up here, after all of ^ & 
				// when it finishes other UIish stuff!



"await Task.WhenAll()"? Be still my beating heart.

Somewhat related is using Visual Studio plus ReSharper to build iOS and Android apps. My only hesitation is it took about 10 seconds from the time I hit F5 on the PC to the time I was debugging (with breakpoints and stuff, mind you) on Mac Emulator or an iOS device. The pros of this great IDE setup outweighed those cons for me personally, but many undoubtedly will prefer Xamarin Studio (or obviously a Cordova/PhoneGap based solution with its super-fast dev feedback cycles).

The biggest win here, however is that the rest of my team had lots of C# experience, minimal JavaScript experience, and no ObjectiveC experience. Xamarin was a slam dunk for our situation.

4. Native Library Interop

Interop wasn't exactly easy with Xamarin, but it was doable, and for a cross platform solution that's a differentiator. As I'll describe, it's also essential to know that it's possible so that if (when) part of the Xamarin abstraction fails you, you can stop cursing the framework and carry on with your life.

The main reason we needed interop initially was our requirement for an expensive physical RFID reader hardware device thingy (that's a technical term) that came with its own proprietary Bluetooth based protocol and set of libraries. If it were a C library, we could use normal P/Invoke semantics to call in. However, since it was an Objective-C API, we needed an iOS Binding Project.

Basically, we defined a bunch of C# Interfaces with Attributes that told Xamarin how to map to the Objective C API's. At compile time, Xamarin code generated an implementation to call the APIs. While Xamarin's Objective Sharpie saved some time by building out some of the many interfaces we needed, it was still a pretty manual process. Basically Objective-C Protocols map poorly to C# Interfaces and some fiddling is involved.

Only once did we need interop because of a Xamarin failing. We needed a dynamic tone generator and despite having audio playback capability (even MIDI libraries), we couldn't get to the lowest level audio APIs we needed (you know, the ones when you need to access sine and cosine and stuff).

Fortunately, interop can solve any problem if you're desperate enough. The good news is we only needed it once, and for a pretty obscure case. Otherwise Xamarin's mapping of the .NET Framework worked perfectly and gave us everything we needed.

5. Minimize Hardware Costs

Warning: My last reason for choosing Xamarin again in a heartbeat will probably apply to 0.001% of readers:

My team mostly has PCs (nice, fast, expensive ones, but PCs nonetheless). Macs are expensive. Building iOS apps requires a Mac. Handing out an extra Mac, even an Air, to all developers on our team for a six month project is a silly expense.

The latest Xamarin Build Host will allow multiple PCs to pair with it. One iMac purchase later and we're good to go. Well, in theory. Technically, that version hadn't come out when we started, so we actually gave lots of money to Apple. But it sounds like a super awesome feature to thwart Apple from receiving lots of money (..oh wait).


A good platform is one that boosts your productivity, allows you to share more and write less code, has great documentation and community support, and gives allowances for its own potential failings. Xamarin has all of this and more.

I'm really looking forward to the opportunity to use it again. Give it a try, I bet you will too.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Lee P Richardson
Web Developer
United States United States
Lee is the author of Siren of Shame, a USB siren currently monitoring continuous integration builds in over 300 companies in 28 countries across the world.

News sites including CodeProject, Visual Studio Magazine, and have published nearly two dozen of Lee's technical articles since 2006. He is an avid blogger at with more than 75 posts over the last decade.

He has worked in software development in the Washington, DC Metropolitan Area for close to 20 years and is currently a senior developer at InfernoRed where he is building cross platform iOS and Android applications for the banking industry.

You may also be interested in...

Comments and Discussions

QuestionStill on the fence... Pin
Chris Maunder19-Oct-17 14:10
adminChris Maunder19-Oct-17 14:10 
GeneralVery good. Pin
Valery Possoz17-Dec-15 8:47
professionalValery Possoz17-Dec-15 8:47 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.171020.1 | Last Updated 17 Dec 2015
Article Copyright 2015 by Lee P Richardson
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid