Exclusive updates on:

MonoMac Offers .NET Style APIs for Cocoa Development

by Jonathan Allen on Mar 29, 2011 |

MonoMac, the newest attempt at creating a GUI toolkit for C# on OS X, has hit its 1.0 release. MonoMac is designed to be much more consistent with other .NET/Mono libraries. This is done by offering a thicker wrapper around the Cocoa APIs that obeys the .NET Framework Design Guidelines.

The earlier libraries such as MonObjc and the deprecated CocoaSharp used a thin, often mechanically generated interop layer on top of the Cocoa APIs. These require the use of selectors, which are a form of message passing OOP used by Objective-C . Rather than mapping selectors to C#’s method-based OOP, these libraries simple expose a series of objc_msgSend functions. The version of objc_msgSend needed depends on the parameters, the return type, and occasionally the CPU architecture.

The alternative to using a library over native code is to use a cross-platform toolkit. The options here are familiar. Gtk# and the deprecated Windows.Forms are easy to use, but don’t offer native-looking applications. And of course there is Silverlight, which encourages you to heavily style the application in lieu of attempting to mimic native applications.

As mentioned before, MonoMac was designed to expose most of Cocoa using .NET conventions. This means you can safely subclass Object-C classes with normal overriding and base-class constructor calls. Client code can hook into event notification via both Objective-C style delegates and .NET style events. Delegates, lambdas, and closures in .NET can be mapped to Objective-C blocks.

MonoMac includes support for publishing to the Mac App Store. Applications are assembled for the store using the Mono bundler, which includes a copy of the Mono runtime so that users don’t need to download it separately.