There is essentially no language specific documentation in well made APIs. There is a common type system so there is very little that's different. Mainly if you need a semicolon and how you prefer your parentheses.

There are some poorly made APIs, like ASP.NET MVC that exploit C#-specific side effects to compensate for C#'s verbosity. These APIs ignore the common type system and just pass object everywhere, breaking tooling and type safety.

But as long as Xamarin didn't come up with terrible designs, you're all set. And, even if they do rely on something strange, F# is such a better language, that the small setback of dealing with interop (which doesn't require learning C#) is totally worth it.

I'm an F# developer, but still decided to not use F# to build an android app. Dealing with the UI libraries like support.v4 was just too painful from a functional perspective. If you don't need any object oriented dependencies, then it's smooth sailing.

F# is not meant for implementing the complete app anyway. Just use it for business logic where it makes sense.

I've only heard that in context of A: missing tooling, B: Microsoft, in their quest to make customers feel C# is still the real language and F#'s just some science toy. I've used F# for a Web UI via WebSharper and it was lovely. It's just a poor reflection on the state of UI kits if they don't work with F#.

"It's just a poor reflection on the state of UI kits if they don't work with F#." - well at least they don't start using lower-case names randomly.

Out of interest what language are you coming from?

I'm all over the map. My day job requires tons of quick and dirty data analysis or concept prototyping which tends to get thrown away, which moves me towards declarative langugages (lots of SQL and Prolog) as well as pragmatic dynamic languages (Clojure,R,Ruby). But if I'm actually building anything that is meant to last more than a month, I tend much more strongly to an ML philosophy. Currently that is mostly Scala and some Rust, but I've been wanting to play with F#/OCaml for a long while.

You might want to consider F# over C# then, there's very little cognitive barriers to using the .NET framework with F#. For example:

    open System.IO                 // F#

    using System.IO;               // C#
    

    let thing = new Thing(a,b,c)   // F#

    var thing = new Thing(a,b,c)   // C#


    Console.WriteLine("blah")      // F#

    Console.WriteLine("blah")      // C#

Essentially C# parameter lists become tuples in F#. So interop is mostly quite straight-forward. It's mostly quite a mechanical process to convert C# sample code into F#.

It's harder to go the other way, and take F# code into the C# world, because functions in F# allow for partial application. The type inference system is awesome, so you'll end up with more generic functions and use first class functions more. That stuff is tricky to bring back (though not insurmountable).

The OO grammar is a little tricky in F#, but I tend to shy away from that. It's not needed most of the time.

Then at least you don't have to deal with all the stuff this library is trying to solve ;)