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.

closed as too broad by gnat, durron597, Ixrec, user40980, GlenH7 Sep 5 '15 at 13:11

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You may check docs.asp.net/en/latest/getting-started/index.html and code.visualstudio.com. Visual Studio and .NET have been made open source. Hoep that solves your purpose. But yes, if you are looking forward to create GUI App, then I don't think it's still possible. – Krishnandu Sarkar Jun 16 '15 at 12:23
  • They have Xamarin.Forms now in the paid version. It doesn't do everything, but it does quite a bit. It allows you to develop a cross-platform GUI. – MetalMikester Jun 16 '15 at 17:57
  • @KrishnanduSarkar what are you talking about? What does ASP .NET have to do with it? :) – Konrad Morawski Jun 17 '15 at 10:08
  • @KrishnanduSarkar plus that's the first time I hear about opensourcing Visual Studio. Would you please provide a link to that information? – Konrad Morawski Jun 17 '15 at 10:18
  • @KonradMorawski It's not. I thought of just informing him. That's why I mentioned that if he's looking forward to create GUI app this will not serve his purpose. Well link is already given in my comment. – Krishnandu Sarkar Jun 17 '15 at 11:35
  1. 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 :)

  2. "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.

  3. 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.

  4. 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.

  5. "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.

  • You could mention github.com/mono/xwt as well, it is an abstraction layer for GTK#, MonoMac, Xamarin.Mac and WPF for GUI. – Residuum Sep 4 '15 at 12:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.