I’ve started working on a Xamarin project a few months ago. We were a team of 1–3 programmers (depending on the stage of the project) and a designer.
With the client wanting both iOS and Android apps, we thought about giving Xamarin a try. All of us being Android developers and none of us having any experience whatsoever with Xamarin, we started by looking into the difference between native development (in Xamarin) and Xamarin.Forms.
The known requirements at the time where:

the UI should look the same on both iOS and Android, so some customization would be needed.
should be able to support text formatting.
should be able to play videos (youtube or mp4).
we wanted to use Firebase as the backend, so that had to be taken into consideration as well, given that Google didn’t add support for C# (although a few years ago it was promised by the Firebase team).

With all of this in mind, I started doing some Xamarin research and demo applications so that we could test the wanted features between Xamarin native development and Xamarin.Forms.

What we’ve learned after those weeks can be resumed something like this:

Xamarin Native:

You have 3 projects: common code, Android and iOS. The common code can be used by both Android and iOS projects. The native projects are structured close to what you are used to in native development.
The common code can only contain business logic, that will be used in the native projects.
PRO: by using Xamarin Native, you can write (almost) any code you would write in native code, just in C# instead of Java, Objective-C or Swift. If you know C#, then the learning curve should be quite easy.
CON: by using Xamarin, you are taking a risk in that the platform would most likely lack support from your favorite library, and you would have to learn a new one (if there are alternatives).
PRO: You can however take the libraries and bind them (in case of .JAR/.AAR) or link them (in case of Objective-C libraries) to Xamarin.

Xamarin.Forms:

You also have 3 projects: common code, Android and iOS, and again the common code can be used by both Android and iOS projects. The platform projects have some limitations: for example, in Android, you have only one activity, and in iOS you don’t have a storyboard.
The common code can contain everything, from business logic, to the app pages. If your app is not very customized and you are pleased with the native buttons, labels, text fields (ie: the control views and layouts) and don’t need much customization on them beside some color changing, your whole app will be in the common code.
The platform code should not add a new page/screen. All the pages should be in the common code.
The platform code can contain business logic which is different between platforms. Also, here you can define the custom views to be used in the common code (more on that soon).
If you want to use a native library, you can only use it in that platform’s project, which makes sense. Let’s say that you want to use Retrofit in your project (which you shouldn’t in a Xamarin project, but that’s another topic). Retrofit is an Android library, so if it where to be used in the common code, then the iOS project wouldn’t understand what to do with that code. You can however use Retrofit in your Android project and another library in the iOS project, and use them in the common project through an interface and IoC (more on that soon).
PRO: write once, run everywhere.
CON: lack of libraries. If for Xamarin Native you can use native libraries with some work, you can bind a library and use it in forms.
PRO: powerful Renderer framework for when you want a custom view. Basically, you are writing native code (but in C#) to create the wanted view, and use that in the common code (a little more complicated than this, but this would be the concept).
PRO: XAML and MVVM support.

Conclusion:

We went ahead with Xamarin.Forms.

Because our app used custom views for every control in the app, we had to write custom renderers for that, and of course, test that they feel, work and look the same on both platforms. Also, given that we used Firebase, we had to use the platform’s specific libraries.
Some stats at the end of the project looked like this:

in the end, we managed to get to 79.14% shared code on Android and 80.05% shared code on iOS.
on Android, 16.32% was for custom views and 4.54% for Firebase.
on iOS, 15.08% was for custom views and 4.87% for Firebase.

My personal opinion is that, if your app is very customized in that you would need to create each page for each platform, you would be better off going full native than using Xamarin at all.

If your app is quite small and should look the same on both platforms, without that many customization needed, then give Forms a go. At first it may be a pain, but as well, it may save some hours and in the end, you’ve learned something new, and for sure, the next time will be easier.

This was a very brief introduction to Xamarin. I hope to add more stories on the development process and some how-to ones in which I go in detail on some of the concepts.
write once, test twice, rewrite twice