Dissecting SemanticMerge, Part 1: how we develop for Mac using C# and MonoMac

Dissecting SemanticMerge, Part 1: how we develop for Mac using C# and MonoMac

Tuesday, March 18, 2014 1 Comments

Objective-C is the language of choice when you go for Mac (and iPhone) but thanks to Xamarin now more than half a million C# developers are able to code for Apple platforms in their language of choice. And this is something good if you’re a Windows developer who need to develop a new app on Mac.

I’m going to share the things we learned while developing SemanticMerge for Mac using C# and MonoMac, and I’d like these posts to be the sort of writing I wish we had when we started our journey :-). This is the part one of a series of posts dissecting SemanticMerge to explain how we develop with C# and Mac

To Objective-C or not to Objective-C

The obvious choice when going to develop a Mac app is going for Objective-C. It is the native language so there’s no better choice.

That being said, there are some situations when you might consider sticking to C#:

• Your app will be based on an extensive codebase written in C#. When that’s the case, rewriting in Objective-C or making it interop somehow can be time consuming.
• The deadlines are tight (aren’t they always? :P) and getting proficient with Objective-C is not an option.

While I think the first reason is pretty acceptable, I’m afraid the second one can be a dangerous excuse for a real world application. Let me elaborate a little bit further: you’ll need to learn the foundations of the Mac environment in order to develop a professional app (I mean, anything that is not just a demo).

• You’ll have to read Objective-C code since it is the main source of documentation and unfortunately there’s not so much info in C#.
• You’ll have to get familiar with the Cocoa objects to build your app anyway.

I hope we can help reducing the learning curve with these posts :-)

Native toolkits

Once you’ve decided C# is the right choice (otherwise you’d be reading Objective-C guides already :P) you’ll probably wonder if you should go for a native ‘window toolkit’ or not.

Let me explain it in detail: “wouldn’t it be awesome to have some sort of UI toolkit where you can write your app once and run it everywhere? I mean, this is the sort of thing Mono does for .NET programs, isn’t it?” – Someone would say.

Well, yes and no. We’ve developed WinForms apps (check the Mac and Linux screenshots in our gallery) for years and we have run them on Linux, Windows and Mac. You think you save time at the beginning because you have a “write once run everywhere” sort of thing. You don’t. The app looks great on Windows, but it looks alien on Mac and Linux. And users will notice immediately, specially the Mac ones.

So, no, don’t go for a “one size fits all” here. You’ll have to spend time writing a MonoMac app even if you already have a wonderful WPF or WinForms one.

“What about things like Qt then?” – I hear someone crying – Well, yes, Qt is cool if you’re a C++ developer, but the C# wrappers, while they’ve been around for ages, seem to lack solid documentation and evolution.

Conclusion

We decided to go with C# and MonoMac because we were very familiar with the language (we love C#, we’d love C# for system programming even more :P) and we had to reuse most of our codebase.

We also used the development of Semantic in C# and MonoMac as an experiment (or pilot project if you prefer) before porting the entire Plastic SCM GUI to Mac.