Life after Prism (1.0)

In the first post of this blog series, we’ve taken a look at the new Add Reference pane for Mono that will be coming to a future prism release. Today, i want to talk about a feature that, technically, already ships in the current 3.0.15 release, but simply is not exposed via a nicely wrapped up template, yet.

When i was at PDC, i had the chance to catch up with Geoff Norton, who is the driving force behind the Mac OS X support in Mono. We talked a bit about the future of Cocoa# and Geoff suggested i should have a look at a third party library called Monobjc, which tries to solve the same problem as Cocoa# – making the Objective-C classes that form the basic of Mac OS X’s APIs available to managed code – but is at a much more complete state and provides better performance.

I liked a lot what i saw when i first looked at Monobjc in early November. From a user (read: developer) perspective, the library works very similar to Cocoa#, seems to be more stable and exposes a lot more functionality. The main differences for developers using Monobjc is that it maintains the original class names from Objective-C (Cocoa# dropped the NS prefixes, which i always thought was a mistake and caused a lot of confusion, not to mention duplicate class names that forced you to use System. or Cocoa. namespace prefixes all the time), and that it uses slightly different attributes to define the mapping between managed and unmanaged code.

So i set out to adjust the IDE support for Cocoa# development we have in Prism, to provide similar functionality for Monobjc. Basically, the development process will be the same as outlined in our wiki article on Cocoa#, but:

A new Custom Tool (MonobjcNibGenerator) is provided to generate code from the elements in your NIB file to match what Monobjc expects. As explained above, this mainly constitutes of using different class names and different attributes; NSObject instead of Cocoa.Object, etc.

![](http://blogs.remobjects.com/blogs/media/blogs/mh/MonobjcCustomTool.png) - Secondly, our [MacPack](http://prismwiki.codegear.com/en/MacPack_%28MSBuild_Task%29) MSBuild extension was updated to provide a new **Monobjc** option, because Monobjc expects the application bundles to be packed up slightly differently.

All of this is present in the current Prism release, if you know how to use it. What’s missing is a nice template that wraps everything up and gets you going with one click, as our current Cocoa# templates do. I would have loved to include that, but by the time the above features were going into SVN, we were less than a handful of days from RTM, so i could not really justify adding a new official feature and get it thru QA ;).

So what’s missing – and coming with the next feature release of Prism – is this:

![](http://blogs.remobjects.com/blogs/media/blogs/mikeo/MonobjcTemplate.png)a nice template that brings it all together and makes using Monobjc in Prism as easy as using Cocoa# is now!

I’ve been using Monobjc myself over the last few weeks, building a Mac OS X user interface for our upcoming DAServer6 (which will be part of Data Abstract later in 2009), and so far i must say i’m very happy with what i’m seeing. Cocoa# has numerous known bugs where applications would just crash if you pressed the wrong key or button, and severe performance problems when lots of round trips between managed and unmanaged code (such as when populating an NSTableView) happened. With Monobjc, i have seen no such problems; it runs stable and speedily, and the running application is literally indistinguishable from a “native” app.

I would certainly recommend giving Monobjc a try if you are doing Mac development with Prism.