I see lots of old information on this question, and lots of articles flying around the Interwebs, but I can't tell quite where things are at.Basically, I want to write C# code that I can then compile into a native Windows application, and also compile into a native Mac application (no Parallels, no Wine, etc.).  Can this be done?Are products like Xamarin the way to go?  Xamarin's web site says Use the same language, APIs and data structures to share an average of 75% of app code across all mobile development platforms. but I can't tell what that 25% of app code that is platform-specific might entail ... I also can't tell if they target OSX and Windows, their web site is very mobile-device-centric.[added later]Summary: Xamarin is not designed to make cross-platform applications - what they give you is a way to write Mac applications in C#, using the Mac's GUI operations.  What they recommend is to write all your business logic cross-platform, and then write 2 completely separate GUIs - one for Windows, one for Mac.C#/Qt seems to be in its very early phases (though if anyone is stumbling onto this article in 2016 or later, go check it out).It appears that mono will do cross-platform including GUI, but only if you use Windows Forms.
Can I write a cross-platform application (Mac and Windows) using C#?
c#;windows;cross platform;mac;osx
Xamarin doesn't target Windows, because there is no point - whatever you write in C#, is ready to run on Windows in and of itself. That's why they're only selling licences for Xamarin.Android, Xamarin.iOS and Xamarin.Mac. But what would a Xamarin.Windows abstraction layer be supposed to do? That would be a textbook snake oil product :)Native Windows application - native is a tricky word when it comes to C#. C# apps typically require either .NET or Mono runtime, whether created with the use of Xamarin or not. If you'd like to create native binaries rather than IL, there's solutions such as .NET Native or ngen, but it's a matter independent of using Xamarin. I don't suppose you meant native in this strict sense, but it's good to be aware of this distinction. With C#, even on Windows you typically use a virtual machine of sorts.Xamarin.Mac requires Mono.OSX runtime so that C# code can be built at all. And it bridges Objective-C runtime with Mono.OSX as described in Xamarin.Mac Internals:There is the Objective-C based runtime containing instances of native classes (NSString, NSApplication, etc) and there is the C# runtime containing instances of managed classes (System.String, HttpClient, etc). In between these two works Xamarin.Mac creates a two way bridge so you can call methods (selectors) in Objective-C (such as NSApplication.Init) and Objective-C can call you back (like methods on your app delegate) So yes, the resulting application is native in the sense that it's not - say - a piece of HTML wrapped in some WebView component. You do have access to native UI elements and APIs. It's not native in the sense that it requires Mono.OSX to be installed. In other words, it is as native as C# on Windows gets under default circumstances.You might also want to familiarize yourself with http://blog.xamarin.com/introduction-to-xamarin.mac-seminar/ - it could be dated (2013), but the core thruths hold I believe. Take a glimpse at slide #7.I can't tell what that 25% of app code that is platform-specific might entail - by definition, everything that isn't platform-agnostic, so, pretty much pure business logic, and whatever you abstract away from concrete implementations (like some IRepository interface etc.). Whatever is platform-specific though: user interface, database persistance, 3rd party libraries for Windows or Mac, cannot be shared. The 75/25 proportion is very rule of thumbish, your mileage may vary a lot depending on the nature of your application.Note that I've only had some non-commercial experience with Xamarin for mobile platforms, and it didn't cover iOS (just Windows Phone and Android). If I am inaccurate on any of this, please correct me.