What, if any, are the Microsoft supported options for running C#/.NET 4.0 code natively on the Mac? Yes, I know about Mono, but among other things, it lags Microsoft. And Silverlight only works in a web browser. A VMWare-type solution won't cut it either.

Is there any semi-authoritative answer to why Microsoft just doesn't support .NET on the Mac itself? It would seem like they could Silverlight and/or buy Mono and quickly be there. No need for native Visual Studio; cross-compiling and remote debugging is fine.

The reason is that where I work there is a growing amount of Uncertainty about the future which is causing a lot more development to be done in C++ instead of C#; brand new projects are chosing to use C++. Nobody wants to tell management 18–24 months from now "sorry" should the Mac (or iPad) become a requirement. C++ is seen as the safer option, even if it (arguably) means a loss in productivity today.

  • 2
    Supported by whom?
    – user1249
    Feb 15, 2011 at 20:01
  • Why do you actually care if MS supports it? IMO it should matter more if Apple supports it if you want to target Mac. Feb 16, 2011 at 0:51
  • Going with C++ is not a bad idea. You can have a portable code base and use the native GUI's on each platform.
    – mike30
    Feb 1, 2013 at 15:29
  • 1
    To update this post it looks like MS has taken notice and they will start to support .NET on different OS's though it's not clear how this will be done. You can create cross platform applications with .NET using NOV: nevron.com/products-open-vision.aspx (I work for this company). It generally allows you to code in C# on windows and then compile for Wpf, MAC, Silverlight and soon for iOS and Android. There is a free (community) edition of this product so there is no need to sacrifice productivity and stick with arcane C++. Feb 13, 2015 at 13:56

12 Answers 12


is there any semi-authoritative answer to why Microsoft just doesn't support .NET on the Mac itself?

The best answer is probably that you don't "just support" .NET on the Mac. You spend hundreds of millions of dollars and several years porting .NET to the Mac.

While some things are fully managed and would not require porting, most things are wrappers around the Win32 API (windows, controls, gdi+, cryptography, active directory, COM, enterprise services, device access, sound, video, codecs, winforms, etc, etc).

Every single one of these would have to be abstracted in the backend and remapped to equivalent native libraries on OSX. Of course, there's not going to be a nice clean mapping, so you also have to write hacks upon hacks to get it functioning exactly the same.

Then there's the issue that these APIs on OSX can be brittle and Apple isn't very good at backwards compatibility, so you get to redo your hacks with every major release (and sometimes minor release and hotfixes), racking up a high maintenance cost.

Basically, it's a tremendous amount of money and work for very little gain on a platform whose owner would be against you doing it anyways. And you don't really want to spend money to help people migrate off of your own platform onto a competitor's.

So you are left with not-perfect cross-platform choices:

  • C++, which will still require porting in the future
  • Silverlight out of the browser, for Microsoft support
  • Mono, which does the work to support a healthy subset of .NET, but isn't Microsoft
  • 5
    You spend hundreds of millions of dollars and several years porting .NET to the Mac. Excuse me? That number sounds a little high...I'm pretty sure the Mono-Framework (with support for many more OSs) didn't cost that much.
    – Bobby
    Feb 16, 2011 at 11:41
  • 1
    @Bobby: that's what I'm thinking. Mono+Silverlight seems most of the way there. Add to that some P/Invoke and/or C++/CLI for less mainstream stuff (Cryptography, AD, etc.) and I think you'd have a pretty reasonable solution at reasonable cost. My argument is that Microsoft DOES want to spend money helping people get on OSX; if they don't, people will stop using C#/.NET on Windows.
    – Ðаn
    Feb 16, 2011 at 14:36
  • @Dan: Exactly, Microsoft does not want to be compatible with the world, otherwise the world could use something different. ;)
    – Bobby
    Feb 16, 2011 at 15:11
  • 15
    The Mono framework is also not a complete, fully tested, documented, supported solution. There is a difference in what's "good enough" for open source and the quality people expect from Microsoft. It would easily cost hundreds of millions of dollars for them to do it to the level users would demand. What they could do to lessen the investment would be to pick out a popular (and portable) subset of the .NET framework and just do it. That's what they chose to do, they call it "Silverlight".
    – jpobst
    Feb 16, 2011 at 15:58
  • @jpobst but yet it looks like MS has done just that ... and more?
    – Ðаn
    Feb 23, 2017 at 14:31

No, Silverlight is the only Microsoft option from .Net on OS X. Mono does not "lag" as much as you think; it supports .Net 4.0 and C# 4, for example. However, the UI toolkits (WinForms and WPF) are not well supported on OS X. Mono doesn't support WPF at all. Neither could Microsoft without rewriting the entire rendering engine. That's probably OK, though. If you want to write a native Mac app, you should be writing a native UI (perhaps using MonoMac).

  • Management doesn't seem very inclined to go along with the Mono option. And it certainly didn't support .NET 4.0 on the same day as on Windows (or?).
    – Ðаn
    Feb 15, 2011 at 19:47
  • Isn't Silverlight already most of the way there on the WPF(-like) front? Yes, the XAML would need to be different to get a Mac look-and-feel.
    – Ðаn
    Feb 15, 2011 at 19:52
  • 2
    @Dan: The way Mono moves these days, if you start developing an app for the latest version of .NET when Microsoft releases it, Mono will support that same version by the time that app is ready to ship.
    – Anon.
    Feb 15, 2011 at 20:13
  • @Dan SL and WPF under the covers are attempting to merge as much as possible. There are technical differences but the fundamental concepts are cross platform. Feb 15, 2011 at 20:21
  • 6
    If your companies management is not willing to use Mono then you will be unable make a desktop application written in traditional C# 4.0 its just that simple.
    – Ramhound
    Feb 15, 2011 at 20:29

No. Mono's your best bet.

Other open source projects like DotGNU may serve you as well. http://www.gnu.org/software/dotgnu/ But none of these is MSFT supported.


Silverlight is not browser only. Since version 3 OOB has existed and would be the route I would take if a Microsoft supported platform is a must-have.

While Mono may lag it is not as removed from the .NET stack as you may think and should not be cast aside as a viable option.

As to why Microsoft does not implement the entire .NET stack; ROI.

  • But it seems like they're oh-so-close with Silverlight...why not just finish the job? That would seem so much better for everybody than Mono reverse-engineering the compiler, CLR, etc.
    – Ðаn
    Feb 15, 2011 at 20:25
  • 1
    SL is not the entire .NET stack. The SL runtime versus the entire .NET stack are completely different animals. Feb 15, 2011 at 20:27
  • Yes, but since you can already do things like OOB as you suggest with SL, why not port the rest (1/3? 40%?) of the .NET stack? Or is SL really nothing more than an attempt to kill Flash?
    – Ðаn
    Feb 15, 2011 at 20:30
  • @Dan When companies are pushing things to the cloud...the last thing that you want to do is port a stack over that can't run in the cloud. SL can run across browsers. You can argue with the likes of Google and others the push for working within a browser is real. Why at this moment would you then opt to port an entire stack to an OS with < 10% market share along with virtualization so prevalent in this day and age? Feb 15, 2011 at 20:44
  • Microsoft (arguably) has the best development environment available today with C# and .NET. But companies like mine will increasingly shy away from it because of the Uncertainty surrounding the Mac/iPad/cloud/etc. C++ seems much safer.
    – Ðаn
    Feb 15, 2011 at 20:50

Most of Microsoft’s profit comes from two products - Windows and Office. Cross platform compatibility would hurt Windows.

If you really want the same code running cross platform, write a web app. It doesn't sound like you do though. “Just in case” isn’t a good reason, it’s scope creep.

Even if you do decide to target Mac OS X or iOS in 16 months from now, do you really think you could take your existing C++ code and turn it into a good (or even functional) native app? Unless you're working on a full-screen game, the answer’s no.

Save time with C# now, and if you decide to move onto the Mac, rewrite it the Mac way with Objective-C and Cocoa - your users will thank you.

  • 1
    "Just in case" is the reality; no one wants to tell management "oops" when there is a safer option in C++.
    – Ðаn
    Feb 15, 2011 at 20:36
  • 1
    Assuming the interface code is properly separated, it will be easier to move C++ code onto the Mac. Rewrite the interface in Objective-C using Cocoa, link to the rest, and you've got a whole lot of the job done. Feb 15, 2011 at 20:43
  • @David: and hence the problem behind this question: more C++, (much) less C#. I (really) like C#!
    – Ðаn
    Feb 15, 2011 at 20:51
  • These cross-platform concerns right here is why a lot of us are still using Java and not moving to C#. Feb 15, 2011 at 20:54

is there any semi-authoritative answer to why Microsoft just doesn't support .NET on the Mac itself?

Where's the market that would justify MS spending the treasure coding it? In order to do this, they'd have to drop serious cash--millions of dollars in salary. An ongoing process, as fixes and updates come along.

And for what? Bragging rights? All they get out of it is the ability for people to ditch Windows for Apple and be able to still run their apps.

If anyone would profit from doing this, it would be Apple. Make it easier for people to transition to their platform and for developers (DEVELOPERS DEVELOPERS) to code on it. But do you think SJ gives a crap? They'd rather invent new stuff to stick an i infront of. Besides, most of the framework is OS and the CLR specs are free for anybody to implement. You can't stick a filthy NDA on any of it.

  • Part of "what's in in for Microsoft" is to keep people using their top-notch tools on Windows. The way things are going around here, C#/.NET will be relegated to in-house apps. Developers who have been using C# for years are writing C++ again. As for the cost; it would seem like they're about 2/3 there already with Silverlight and/or Mono.
    – Ðаn
    Feb 15, 2011 at 20:14
  • Mono is an open source platform, and while the source for .NET has been released, the .NET Framework is NOT open source. Microsoft will be unable to purchase Mono, for many reasons, the major one is that they do not have a single 100% open source application. Do you know know that Silverlight is only a single language within the .NET and the reason it is multi-platform because Microsoft would like it to be a replacement for Flash. I should also add that Apple has made hand movements towards not even allowing something this on their operating system.
    – Ramhound
    Feb 15, 2011 at 20:26
  • 1
    @Dan sounds like the solution to your woes isn't "one language to rule them all" but "How do we deploy in a platform-agnostic manner." Most people are accomplishing this by breaking the UI from the logic, embedding one on a per-platform basis and the other as a service on the innertubes.
    – Ripped Off
    Feb 15, 2011 at 20:47
  • 1
    @Dan I have a solution for that... Don't code for the Mac. I have a personal Non Develop-for-Apple Agreement I wrote and signed myself. I would utterly hate not being able to code C#, and so avoid doing so. But sometimes you gotta do what you gotta do, and if wishes were fishes we'd have to think up some other alliteration to describe the many things we want but cannot have.
    – Ripped Off
    Feb 15, 2011 at 21:00
  • 1
    @Dan kindasorta. They haven't really touched the desktop (yet). But I am amazed at what a difference five years makes.
    – Ripped Off
    Feb 23, 2017 at 14:54

You might find the MonoMac project useful - http://www.mono-project.com/MonoMac

It allows for developing Cocoa applications Mono style, which can be deployed to the Mac App store.

I would strongly consider this approach for a developer unfamiliar with Objective-C but with .NET/Mono/Java who has to deliver an application in a time restrained scenario.



I recommend either writing a cross-compilable C++ application - may you have joy in it - or using Ruby with wxWidgets.

I consider .NET a bad proposition for cross-platform development and long-term product maintenance. Although, man, you can whiz out apps fast in it. :-/

Wish Delphi was still a major contender.


If you want to run .NET natively on a Mac, you can use BootCamp to do this (i.e. you run Windows on the Mac, and your .NET applications in Windows).

If you meant Mac OS X rather than just the hardware, then you can use VMWare or Parallels to run the .NET applications in Windows (in emulation) in OS X. Both have visual modes that let your application appear as if it is running only within OS X (it will look and behave like a Windows application, but if you are writing a cross-platform non-web application without a custom interface for each OS you will always have that problem).

You will get the same amount of "support" by doing this, since you're running the app in Windows, albeit virtualized. Of course, anyone running the app will need a copy of the virtualization software, and Windows, and be willing to put up with an app that doesn't behave like an OS X app - but it is the only way to have "native" .NET running on a Mac.


Dan, I don't think you can do this. However, a possible solution (still vapourware) is to use Embarcadero Rad Studio C++ Builder, which has a nice VCL for developing visual applications (upon which much of .net is based), and they are RUMOURED to have cross-platform support coming out in the next release.

This will be develop on windows, target to Mac or Linux. Or so their roadmap says.

The C++ environment is reasonable and if you develop against the VCL then in theory the application will just work on the other platforms.

Of course until its actually shipped it remains to be seen how effective this really is.


The answer is no.

Actually your case seems to be a very good example of when not to choose .NET.

  • Nobody can predict the future and nobody wants to take on "undue" risk.
    – Ðаn
    Feb 15, 2011 at 19:43
  • @Dan: And the point is? You seem to be agreeing with me...? Feb 15, 2011 at 19:47

If you want to develop for an OS then use the right tools. There are no truly professional apps written in mono for the Mac. There is on the other hand a lot of non-professional developers using a lot of tools creating a lot of garbage. Look at the mono app reviews that have been written for OSX. The developers are writing using an incomplete framework hacked to match the OSX platform. Start out write - if you have used C# Objective C is a quick learn.

Professional developers for the mac use C++, Objective C, Cocoa, and Xcode. I develop on several platforms and each has their own best tools. Use Xcode for the Mac and iOS.

Just as a side note Xcode is no Visual Studio it is not as stable and is a disgrace to apple in comparison, but it works well when you get used to he quirks. It is very difficult to beat Microsofts tools - but they were written for Windows not Linux, iOS, OSX, AIX etc.

  • 1
    Do you have any facts to backup statements like "Xcode is not as stable and is a disgrace to Apple" because based on my own personal experience everyone that has used Xcode has loved it. Besides even after you express your personal opinion on a subject it seems your not familar with, you are not even aware that in 2013, there actually is a solution. Of course the solution is actually Mono and Xamarin.Mac but it is a solution. The current version of Mono is nearly a 100% full implementation of .NET 4.0 it only lacks a couple major features which likely will never be ported ( i.e. WPF ).
    – Ramhound
    Feb 1, 2013 at 14:23

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