Few years ago, after releasing the CppDepend product, many users ask us for a Mac OSX version to analyze the Objective C code base, last year we decided to develop XClarify, the CppDepend like for Objective C.
Our GUI was developed using .Net and porting all the code to Objective C has the big drawback to maintain two versions, time for our developement team to make some research on how to reuse our .Net code for the Mac OSX version?
What’s the solution to port a .Net code base to Mac OSX?
When searching for all possiblities, the trivial one was to use Mono, it wasn’t an easy task, specially because we use DevExpress which is not compliant with Mono due to the overuse of P/Invoke calls.
In our first version we used the Mono Winforms implementation to avoid big changes on our code base, and we finally released our beta version. After contacting some Objective C developers to give XClarify a try, we discoverd our big mistake, and here are some feedbacks from Mac OSX users:
Having an application that looks like Visual Studio on OS X is enough of an insult.
I’ve downloaded your product for the trial but when I’m trying to run it it is asking for X11. I’ve read a couple of things on line that says that installing this X11 over Apples could cause instabilities – what are the risks in doing this and why is it needed?
Thanks to beta users we were warned about the biggest mistake we have done and time for us to quickly find another solution to correct this, so how to make a product that meets the Mac OSX users requirements?
The solution was to use the cocoa framework, and fortunately a cocoa porting to Mono is provided by Xamarin which offers the MonoMac library, but using MonoMac will impact all the Gui code base, and we can’t have anymore one codebase to maitain. but we learned well the lesson, what’s more important is not to have one code base to maitain but what the user is waiting for when he uses the product.
We decided for our second version to use MonoMac and remove all dependencies with System.Windows.Forms and System.Drawing libraries to use Cocoa instead.
Concerning removing the dependency with System.Drawing, there’s the following library, but it’s not mature yet, and some blocking bugs will encourage you to not using it.
To make the porting easier, we needed a good Gui library which simplify the Gui developement, and we found a powerful library, named Eto. Its developement team is very active and the library is stable.
After releasing our second version, we had to package the product to a standalone application which must be easy to install without installing other requirements. The MonoMac library is not sufficient for that and you have to use Xam.Mac which is not free.
As conclusion if you want to port your .Net application to Mac OSX, an interesting solution is to use Xamarin Studio, Xam.Mac and Eto libraries, and especially avoid using System.Windows.forms.