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.
- CoreBluetooth
- GameKit
- New MountainLion AppKit APIs
- SceneKit
- StoreKit
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.
He continues,
We are still learning how best to apply MVVM across WPF and iOS (we don't currently support Android with this code base). Data Dashboard itself only supports iPad so all of our UI code was iPad specific. As a result for that app we just used Apple's MVC pattern of having a view controller for each view, and the view controller is backed by a model which could be cross platform.
We are starting now to work on some apps that are cross platform, and for those our current plan is to try to integrate WPF's MVVM pattern into our iOS code. The plan is for the view models classes to inherit from UIViewController (at least where that makes sense), and we use partial classes to isolate the platform specific code into different files.
That said, we don't really do MVVM correctly in the first place. Our view models have references to our views, which is not right for proper MVVM. If we were starting from scratch I would have rather tried to get more isolation between platform specific code and platform agnostic code by implementing MVVM the way it was meant to be done. That means the view model can be platform agnostic, the views are platform specific, and the views bind to the view models.
We did use commanding in Data Dashboard, and we will use it more in our future apps. However, we had to implement our own commanding system in MonoTouch to make it work like it does on WPF. The way Apple does commanding is through ObjectiveC selectors and the responder chain. I have in some cases tried to bridge the gap between those two approaches, but there are a few limitations in MonoTouch that make that difficult.
When told of the Eto, a “Cross platform GUI framework for desktop and mobile applications in .NET” he responded with,
Thanks, but we don't want to use a cross platform GUI API. We want our UI to be designed specifically for each platform using native UI elements so that each UI looks totally native to its platform. Cross platform APIs just end up producing UIs that use the lowest common denominator for all platforms, and they never quite feel right. Touch screen is different from mouse and keyboard, and so UIs for touch should be designed with touch in mind, not ported from a UI that was intended for mouse and keyboard.