First look at Xamarin.Forms

Today (May 29) was the Norwegian national holiday, so it was a good timing for me that Xamarin just announced availability of Xamarin 3 with the main new addition called Xamarin.Forms. So I downloaded both Windows and Mac versions and spent some time checking out how they work. This post is about setting up Xamain.Forms projects, it doesn’t contain a thorough look at its functional capabilities.

Since I have a Mac machine, I decided to try both Windows and Mac versions. To use Xamarin.Forms with Visual Studio I had to install Visual Studio 2013 Update 2 (RTM) – this is a prerequisite, earlier versions won’t work. Xamarin Visual Studio add-on installs 3 new templates in the “Mobile Apps” folder, so you have choice between applications based on Shared (Universal) projects, Portable projects or just building a portable class library (PCL).


I selected Xamarin.Forms portable and Visual Studio created a common portable class library project (with shared form definition) and applications for all three supported platforms (Android, iOS and Windows Phone 8).


The common PCL uses profile that supports five different platorms – in addition to mobile platforms it can also be used in desktop and Silverlight applications.


Then I switched to MacOS, started Xamarin Studio and chose an alternative template for Xamarin.Forms solution – this time it was Shared project template.


Xamarin Studio created a shared forms project and applications for two platforms supported for development on MacOS (Android and iOS).


Now I could start building mobile applications. I switched back to Visual Studio and started with Windows Phone app. For the first time Windows Phone is a target of Xamarin tools platform (Xamarin Studio still supports only iOS and Android). The actual UI content (placed in a PCL and shared by all platforms) consisted of an obligatory first-app-greeting:


I built a Windows Phone app and deployed it to a phone simulator. Note “PortableApp1.WinPhone” that appears in the application list. Executing it results in a “Hello, Forms!” message.


Next was Android simulator. It took me some time to figure out how to select Android API version required by the app. The trick was to locate a small toolbar button that opens Android options. I chose “MonoForAndroid_API_15”.


Having selected correct version of Android Simulator, I was able to deploy PortableApp1.




The last platform was iOS, it required establishing a connection with Mac host. I also had to choose the Simulator device type.


After the iOS deployment configuration was correctly set, Visual Studio deployed the iOS app to the iPhone simulator running on Mac.


Having completed all three applications from within Visual Studio, I switched back to Xamarin Studio on Mac. There is no Windows Phone support in Xamarin Studio, so I built Android and iOS apps. The content of App.cs file in a Shared project is almost identical to its Portable project counterpart. And the Android simulator on Mac OS looks similar.


Next was iOS app and choice of its simulator.


After the deployment of iOS app I had both PortableApp1 and SharedApp1 installed on the iPhone simulator – the first one was earlier installed by Visual Studio.


After completion of apps with Xamarin Studio I tried swapping solutions between development environments. Here not everything went smooth. Xamarin Studio opened and built the solution created with Visual Studio (of course with exception of Windows Phone project that was ignored), but Visual Studio refused to load shared app project with a cryptic error message:


The log file contained a stack trace of the AggregatedException with not much more useful details. I described an error in Xamarin forum, and one of the suggestion was to install a Shared Project Reference Manager extension. I followed the advice, and while I no longer received the error above, Visual Studio still refused to deal with the shared project, this time hanging on project load.


I also tried to create a solution based on Shared project template in Xamarin Studio for Windows, but the result was still the same: Visual Studio couldn’t handle the solutions created by Xamarin Studio. It looks like the problem is only with Shared project template – when I created with Xamarin Studio a project from Portable project template, Visual Studio had no problems with it.

So for the time being if you want to be able to swap solutions between different environments, you need to create Shared apps with Xamarin add-in to Visual Studio which can be a problem because this option requires the expensive Xamarin Business license. Hopefully this issue will be addressed soon.

I also tried to get a feeling of what it takes to author UI content in Xamarin.Forms, so I used code from a login page example.


I only needed to edit this code once – in a Portable or Shared app, and all apps reflected the change.



This a very trivial example, and I am looking forward to check more advanced scenarios. During beta testing period Xamarin.Forms had a codename QuickUI, and it’s a really way to simultaneously develop applications on all three major mobile platforms. There is no restriction in mixing native UI elements with content created with Xamarin.Forms, so the resulting apps don’t need to suffer from least common denominator design syndrome.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s