My experience with Xamarin is mostly on the Android side, so that's what I'll mention. Spoiler: mostly positive, with some big caveats.
In no particular order:
Stay the hell away from Xam.Forms, unless it's improved drastically in the last 6 months. Though I also think the whole idea is misguided.
For Android, go with Xamarin or Kotlin. I would take C# over Kotlin because of the maturity of the language, the tooling around the language, and the ecosystem. Either way, having a powerful modern language will be a godsend.
Concurrency on Android is much easier to deal with in Xamarin than with native. This extends to things like complex orchestration of animations.
You will do backflips trying to get startup-time down. But once your app is in memory performance is basically native-level.
Xamarin gives you some nice framework-level things that native Android doesn't. A good API for sqlite and http. Proper data-binding. MvvmCross and ReactiveUI are light-years ahead of anything that is available in native-land.
Xamarin builds are faster and more reliable than Gradle.
Xamarin introduces its own layer of bugs and glitches. You've added another slice of Swiss cheese to the stack.
Xamarin plugin for Visual Studio is crash/glitch city. Xamarin Studio is tolerable at best. Either way, your tooling will be faster but less feature-rich than Android Studio.
Every time you want to use an existing third party library, you will go through this process: Has anyone done an official binding for it? If yes, use awkward Java syntax in C#. If no, try to find an unofficial binding. If not found, try to bind on your own - 50% chance it just works, 50% chance you fiddle for half the day and then fail. If it's the latter, try to decide if you want to do a code-level port, or abandon your idea. Code-level ports are possible nearly line-by-line, it's slow brainless work.
I will re-iterate the "Stay the hell away from Xam.Forms" as we've used it at work for almost 1.5 years.
I just convinced our management to move away from it when I migrated a page from Xamarin.Forms to regular Xamarin.Android. The page render time went from 2,000ms to 400ms.
A quick glance on the now-open source code of Xamarin Forms now shows you why the perf is so sluggish (the whole thing seems like it was hacked together by a college intern as a week-end project).
Xamarin seems to have a marketing team that is far ahead of their development team.
In no particular order:
Stay the hell away from Xam.Forms, unless it's improved drastically in the last 6 months. Though I also think the whole idea is misguided.
For Android, go with Xamarin or Kotlin. I would take C# over Kotlin because of the maturity of the language, the tooling around the language, and the ecosystem. Either way, having a powerful modern language will be a godsend.
Concurrency on Android is much easier to deal with in Xamarin than with native. This extends to things like complex orchestration of animations.
You will do backflips trying to get startup-time down. But once your app is in memory performance is basically native-level.
Xamarin gives you some nice framework-level things that native Android doesn't. A good API for sqlite and http. Proper data-binding. MvvmCross and ReactiveUI are light-years ahead of anything that is available in native-land.
Xamarin builds are faster and more reliable than Gradle.
Xamarin introduces its own layer of bugs and glitches. You've added another slice of Swiss cheese to the stack.
Xamarin plugin for Visual Studio is crash/glitch city. Xamarin Studio is tolerable at best. Either way, your tooling will be faster but less feature-rich than Android Studio.
Every time you want to use an existing third party library, you will go through this process: Has anyone done an official binding for it? If yes, use awkward Java syntax in C#. If no, try to find an unofficial binding. If not found, try to bind on your own - 50% chance it just works, 50% chance you fiddle for half the day and then fail. If it's the latter, try to decide if you want to do a code-level port, or abandon your idea. Code-level ports are possible nearly line-by-line, it's slow brainless work.