How It All Started

Xamarin.Forms is only a small part of the greater solution that is called Xamarin. Xamarin is both the name of the technique and the name of the company that is behind it. But before it became the company as we know it, there has been a lot going on.

It all started with Miguel de Icaza and Nat Friedman, both still heavily involved. They founded a company together in 1999, which eventually will be known as Ximian. At that time, they were focused on developing GNOME, which is a desktop environment for Unix-based systems.

Soon after Microsoft announced the .NET Framework in June 2000, Miguel started investigating whether a Linux counterpart would be possible. This led to the launch of the Mono project in July 2001. This open source project is basically the foundation of Xamarin. Back in 2001, the goal was set to run .NET Framework applications on other platforms.

In 2003, Novell acquired Ximian, along with the Mono project. Novell was known for being one of the first companies that facilitated thin clients, by being able to run applications on the server. The acquisition of Ximian was the start of transitioning their product suite to a Linux base.

After three years of development, major version 1.0 of the Mono project was released in 2004. This was only a year before Microsoft released version 2.0 of the .NET Framework. As you may recall, Microsoft did not support the open source idea back then. Because of that, support for Mono would always be behind the implementation of Microsoft, and as time passed, this gap was quickly closed. However, some form of collaboration happened and was further expanded in 2006. During the time that Ximian was under the care of Novell, Mono did not live up to its potential.

After a lot of hard work in 2009, Mono Touch, the foundation of Xamarin as a technology, was released. With the release of Mono Touch 1.0, C# applications could be submitted to the iOS app store. Actually, at some point around the iOS 4 release in 2010, there was a little dispute on Apple banning Mono Touch applications (along with Flash) from the app store. Apple updated their license agreement with:

“Applications may only use documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the documented APIs (e.g., applications that link to documented APIs through an intermediary translation or compatibility layer or tool are prohibited).”

This meant that all cross-compiled apps would not be allowed, including Mono Touch applications . The main reason would be that Apple would lose control over the ecosystem they had created. After a lot of criticism, the rules were toned down a little, allowing other programming languages to be used. However, as a side note, you still need Mac hardware to compile your iOS applications.

Also in 2010, Novell was acquired by a company called Attachmate. In April 2011, most of the Novell team was laid off. This begged the question of what would happen to the Mono project. And more importantly for mobile developers, what would happen to the Mono Touch project.

Soon after the layoffs, in a blog post, Miguel announced that Mono would find continuation in a newly founded company called Xamarin. Nat Friedman was appointed the CEO of Xamarin soon after.

If you have ever wondered where the name Xamarin came from, consider what Miguel de Icaza said in an interview with adtmag.com: (see https://adtmag.com/blogs/watersworks/2011/05/interview-with-miguel-de-icaza.aspx ):

“We've used monkey themes for many years,” de Icaza said. “Ximian was a play on simian. Mono is Spanish for monkey. Xamarin comes from the Tamarin monkey. And we kept the X; though to tell you the truth, I can't remember why we used it in the first place.”

Xamarin Today

The rest is history, as they say. From the launch of Xamarin as a company, things started to accelerate. In 2012 and 2013, it went a bit silent, but Xamarin introduced their flagship products. Xamarin.Mac, released in December 2012, enabled developers to write C# applications for the MacOS desktop. In February 2013, Xamarin.iOS and Xamarin.Android were released. At this time, developers could share code between iOS, Android, and MacOS. Implicitly Windows Phone, released in October of 2012, was supported as well, because this was already based on C# and .NET technology.

Along with the Xamarin framework , Xamarin Studio was also released. This Integrated Development Environment (IDE ) would be the choice for developing Xamarin cross-platform apps for several years to come.

In the meantime, Microsoft was changing course rapidly as well. A lot of the .NET projects were converted to open source and put on GitHub. Windows Phone was still being maintained, but the future of it seems unsure. Certainly, with the introduction of Universal Windows Platform (UWP) apps, it is now possible to run your app on any Windows-based device, including but not limited to Xbox, HoloLens, Windows Phone, and Windows 10 desktop.

In February 2016, the whole Xamarin crew became part of Microsoft. Not long after that, more good news was in store. At the Build conference, Microsoft announced that the Xamarin development tools would be free and become open source as well.

With the acquisition of Xamarin, Microsoft is a contender in the mobile market. Before, they had a hard time gaining some market share with the Windows Phone, but now they have a full end-to-end C# solution for developing applications. And not just developing!

In December 2014, Microsoft bought HockeyApp , a solution for crash reporting, analytics, and distribution of mobile apps. HockeyApp, Xamarin, and what Microsoft already had in their portfolio combined, makes them the most complete vendor for everything mobile to date as far as I am concerned.

As to be expected, some Xamarin branded components are being replaced slowly by the Microsoft brand. Xamarin Studio is now Visual Studio for Mac with more Azure options; the Xamarin MVP program is fused with the Microsoft MVP program; etc. But I think it will take a while before the name Xamarin will disappear completely, at least at the company level.

But it doesn’t stop at rebranding. Microsoft is also putting a lot of effort into bringing all the acquired solutions together and introduced Mobile Center in November 2016. This user-friendly environment combines all the best parts of Visual Studio Team Services (VSTS ) , Xamarin Test Cloud, and HockeyApp, as well as some parts of Azure relevant to mobile into a single point of entry. While still in preview at the time of writing, there is a lot you can do already. Just before the release of this book Microsoft has taken Mobile Center out of preview. It is now called App Center. Where I write Mobile Center in the remainder of this book, I actually mean App Center. The functionalities should be identical or by the time you’re reading this will even be expanded.

Near the end of this book, we will look ahead to the things that are coming in regards to Xamarin and cross-platform development.

Product Suite

So you can get a better understanding of Xamarin as a whole, this section summarizes all the relevant products with brief descriptions of each.

Xamarin Test Cloud

Another unique service from the Xamarin minds is Xamarin Test Cloud. Test Cloud is a service for automated UI testing of your apps. And not just Xamarin apps either—native and hybrid apps are supported as well!

The services that Test Cloud offers are quite unique. You can write coded UI tests, which run on actual physical devices. This way, you get as close to a user experience as you can get. You do not have to buy a lot of expensive hardware. Test Cloud has over 2500 unique configurations at the time of writing, with about a 100 added each month alone. The results are conveniently shown in a great interface, complete with screenshots and logging, as shown in Figure 1-1. To read more on Xamarin Test Cloud, visit https://www.xamarin.com/test-cloud .

Figure 1-1 Test Cloud result dashboard

Under the Test Cloud umbrella is the Test Recorder, which lets you record tests with an easy-to-user interface.

Xamarin Workbooks

One more notable product is the Xamarin Workbooks , which is kind of a standalone product. While it is invented by the Xamarin team, it doesn’t just target Xamarin development. You can use it with all kinds of .NET-related technologies.

The goal of Workbooks is to blend code with documentation. Because of that, it can be used in a wide variety of ways. Think of interactive learning guides, education, experimentation, etc.

With Markdown —a way of styling text through common characters—you can format text to describe to the reader what your goal is. With the tight integration with Roslyn, which is basically a compiler as a service, code can be executed inline and the results are visible instantly. It also has IntelliSense support and other features. In Figure 1-2, you can see an example of such a Workbook in action, but it is self-explanatory if you start playing around with it.

Figure 1-2 A Xamarin Workbook in action, explaining UrhoSharp

For more information on Workbooks, refer to https://developer.xamarin.com/guides/cross-platform/workbooks/ .

I am probably forgetting some other larger or smaller products, but this is the gist of it. I hope you can see that Xamarin is so much more than just the cross-platform development. While that is the focus on nearly all of the products, there are a lot of awesome tools in this toolbelt.

The Xamarin Vision

This section elaborates a bit more on the vision and unique approach of Xamarin. I do this by explaining a bit more about development before Xamarin and how they are achieving cross-platform development today. That way, you will have a better understanding of the inner workings of Xamarin and Xamarin.Forms.

Before Xamarin, there was the traditional approach of developing native apps. Xamarin likes to call this the “silo” approach . This is shown in Figure 1-3.

Figure 1-3 The silo approach means building one app three times

You had to build your app over and over, for each platform you wanted to support. Each app would, ideally, have the same features, but each was built in its own programming language, in its own IDE. It is not very likely that one person can have perfect knowledge of all these ecosystems, so the silo approach most likely needs multiple teams.

You can see why this has several disadvantages. It costs a lot of time and money to keep all these apps at the same level of functionalities. Also, tests will not be interchangeable, so testing also costs three times as much. And worst of all, you can have different bugs on different platforms. I didn’t even mention the hardware and licenses you would have to buy to support all this development.

If I would have to name one advantage of the silo approach, it is that because each app is written in its own language, the performance should be the best of all approaches. Notice how I am saying should. There are benchmarks that show that Xamarin is marginally faster than native development tools. There are multiple benchmarks out there, but I like the ones by Harry Cheung, former Google engineer. You can read his posts here: https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9 and the updated post here: https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976 .

The next approach is the hybrid approach , also known as “Write Once, Run Anywhere”. Think of solutions like PhoneGap and Ionic. These frameworks mostly allow developers to start off relatively easy, because they are based on web technology. So, you can start writing your app very quickly using HTML and JavaScript or Lua, etc. Figure 1-4 illustrates this concept.

Figure 1-4 The hybrid approach

This way of developing means that you are mostly limited to the APIs that are the common denominator on all platforms. Each phone has a camera nowadays, so that is supported. Not all phones have augmented reality features, so to support that from day one, you have to write Java or Objective-C code. Also, the render time tends to be slower. Even worse, when your CSS fails to load, your user is presented with an ugly app, leaving them puzzled.

Most of the time, hybrid apps also look the same across all platforms. While that seems convenient from a developer’s perspective, from a user perspective, it is not. I will elaborate more on that in a minute when I explain the Xamarin approach.

All in all, the hybrid approach seems to cause more misery than anything else. In all fairness, I haven’t touched any hybrid development solutions in-depth. But I can usually pick out the hybrid apps from the store, and not in a good way.

All of this raises the question: what is native? We often hear that native apps are best. But what does native mean? That is what the people at Xamarin asked themselves before setting out on their journey.

They came up with the following characteristics :

• Looks and feels like it belongs on that platform. The app should adopt the paradigm of the platform it’s running on. Adhere to the navigation pattern, have controls that the user is used to from other apps, and so on. Remember when I spoke of the generic look and user experience for apps with the hybrid approach? That is what you want to avoid. When the look and feel does not comply with the rest of the ecosystem, the user will be confused.

• 100% API access. The developer should have access to all of the APIs that are available on that platform. No exceptions. When some new awesome feature is announced for the new iOS, you must be able to use it in your app. And not just the Apple or Google APIs either, you must also be able to use any third-party API and library out there.

• Provides the best performance. It must provide the best performance. Although it may not be the native programming language, the app still must be responsive and fast.

These days, users have high expectations! When your app is not doing what it should, it is usually uninstalled within 30 seconds and it will be really hard to convince the user to come back after that. So, these statements about what is native are important.

With that in mind, Xamarin came up with their own approach to things, as shown in Figure 1-5.

Figure 1-5 The Xamarin approach to cross-platform development

Xamarin basically created mappings for all native APIs and made them available through C# and .NET. In fact, it makes perfect sense, because Microsoft has been doing this for years. Whenever you started a WinForms project, you would get the base .NET Framework libraries, with a set specific to WinForms as an addition. Planning on an ASP.NET application? You get the same set of base libraries and a specific set to ASP.NET.

The team at Xamarin created so-called projections. Each method, object, property, etc. that is available in Objective-C of Java Xamarin is available in .NET with its own types. That way everything is available to the developers, most of the time from day one.

Especially for iOS, Xamarin has an unbeaten track record since iOS 5. The day that Apple releases the new (final) iOS version, Xamarin has updated their bits, and everything is available to you as well. For iOS, this is important, because the adoption rate on a new iOS version is quite high. On Android, not so much. Months after an update is released, people are still stuck on the older version. So, the same-day support isn’t as relevant. That does not mean that Xamarin is lacking with adding new APIs. Although it may not be the same day, it is soon after release. If you miss anything, like support for some third-party library, Xamarin has you covered. The tools that are used internally to create the projections are available to you as well. That way, you can create your own binding library for a native API if you want to.

The statement Xamarin has always carried out is the following:

“Anything you can do in Objective-C, Swift, or Java can be done in C# and Visual Studio with Xamarin.”

I still haven’t found anything to counter that statement.

When Microsoft took over, things went a step further. With developments like .NET Core and .NET Standard, cross-platform development is looking better than ever before. This enables developers to develop code that is truly useable across platforms. In Figure 1-6, you can see an example of that.

Figure 1-6 Example of an architecture with end-to-end C# code

I’d like to end this chapter with the new mantra that Microsoft is now putting on the Xamarin branch:

“Any Developer, Any App, Any Platform”

I love it!

Summary

I hope you enjoyed reading this chapter as much as I did writing it. Although I only did a quick recap of all the facts, it is an absolute joy to read this story. A lot of things had to go right (or wrong, depending on where you’re standing) to make all of this happen and put Xamarin where it is in the world today. Personally, I love the passion of namely Miguel, but also Nat and all the people making this possible and who kept believing in their solution. While it hasn’t always been perfect, it was never because of lack of trying. When you realize what Xamarin is trying to do, it’s a miracle something works at all. The thing they are trying to do is make all kinds of different Software Development Kits (SDKs ) from all types of vendors, each with their own attitude and quirks, work together in one stable, easy-to-use solution. That is hard to maintain when you are so dependent on others all the time.

This works the other way too—make no mistake, mobile development is hard. If you thought .NET exceptions were hard to read, wait until you see some Java ones. And now you do not need to know about one development ecosystem, but three at least. While Xamarin is making it the best they can, it’s not always a breeze. Especially when you’re just getting started.

The sources I used for this chapters are various, including some stories I picked up in sessions and conversations I had over the years, but also these:

• Strikingly: http://corefx.strikingly.com/

• Wikipedia: https://en.wikipedia.org/wiki/Xamarin , https://en.wikipedia.org/wiki/Novell , https://en.wikipedia.org/wiki/Miguel_de_Icaza

• Adtmag.com: https://adtmag.com/blogs/watersworks/2011/05/interview-with-miguel-de-icaza.aspx

In this chapter, you learned how Xamarin became Xamarin and where it stands today. It also explained the Xamarin vision and how extensive their suite is. You learned about the landscape of the various mobile development approaches and read about how Xamarin works its magic. This way you will have a better understanding of what is coming in this book.

In the next chapter, I zoom in on Xamarin.Forms specifically. You will see why Xamarin.Forms was necessary to allow for more code sharing and will learn how it works.