Xamarin, makers of the popular MonoTouch and Mono for Android platforms, have entered into the Mac App Store market with Xamarin.Mac.
This isn’t the first someone tried to create C# bindings for OS X. Previous attempts include Cocoa Sharp, Monobjc, and NObjective. Part of what makes this attempt different is that it is a commercial offering, Xamarin has a financial stake in not allowing the bindings to become obsolete.
You may notice that MonoMac is missing from the above list. That’s because Xamarin.Mac is an extension to MonoMac. In addition to removing the LGPL licensing restrictions, Xamarin.Mac offers a few advantages over MonoMac.
Most importantly, it creates fully self-contained applications. Users will not need to install Mono separately, which is a requirement for the Mac App Store and a convenience for everyone else.
Xamarin.Mac also includes support for frameworks that MonoMac overlooked.
- New MountainLion AppKit APIs
Xamarin.Mac is currently targeting MacOS X Lion and Moutain Lion. Xamarin also recommends developers use the most recent version of Xcode, currently 4.5.2.
While Xamarin.Mac will allow developers to share business logic between the various platforms, anything that touches the UI will need to be rewritten for the Mac. Rather than offering a cross-platform toolkit, Xamarin is encouraging developers to use native bindings to ensure the applications look right on each device.
For many developers, this has been a long time point of contention. They would rather have a XAML-based UI language, possibly based on Silverlight/Moonlight, that offers a “write-once, run-anywhere” experience. Some have even expressed interest in XAML even if it isn’t reusable across platforms because of rich support for styling and animations.
When asked, adamkemp of Data Dashboard had this to say about the topic of code reuse,
I am one of the lead developers for Data Dashboard for iPad, which is the first case study app mentioned in the announcement. We got quite a bit of code reuse from C# code written for WPF/Silverlight. The UI parts or totally different, but there's a lot of non-UI code in a large app.
Read more: InfoQ