Porting WPF to Cocoa (and/or vice-versa)

Question

I am in the beginning stages of creating software for a mISV-to-be. The program is a desktop application and in the long run I want to have a native version for both Windows and OS X (I have a looked at various cross-platform APIs, and none of them meet my needs). Initially though, I don't think it makes sense to develop for two platforms at once. With that in mind, I have been looking at WPF for Windows and Cocoa for OS X, and they seem similar.

Has anyone had experience porting one to the other? Are there particular techniques/paradigms to follow that will make porting easier? Ignoring business considerations, would you recommend developing on one of them first?

Answer 1

Well, there is not a straightforward path. The best method is to use something like Model-View-Controller pattern or some other architecture to separate business logic and so forth from the presentation. However, unless you are using Mono, there will be very little code for you to share, I think.If you are developing WPF then you surely doing .NET and, other than Mono, Objective-C is the standard programming tool under Mac OS X.

Keep a good design and you can have most of your code simply be an Objective-C version of your .NET code and vice versa rather than trying to find a migration path.

Answer 2

Well. Once you've written an app for Cocoa, it is possible to port it to Windows. This could be done using gnustep or Cocotron.

If you do it the other way, WINE is meant to make porting easier.

I would rather write the OSX version first. This is because Windows users have no clear idea what they want an application to look like. In my experience, they are quite able to suffer through all kinds of user interfaces. Consistency has little value to them. Since there is no common agreement, what a Windows app should look like, nothing stops Windows users from actually liking OSX designs, and they even frequently do. iTunes for windows looks like a very typical OSX app and you hear very few complaints that it would not be enough Windows-ish.

Going the other direction, this is not true. OSX users have a clear preference for Cocoa apps and very little tolerance for, as an example, things like GIMP or Inkscape which work under OSX just as well as anywhere else, but look plainly ugly to the OSX trained eye.

Answer 3

I think that you're on the right path by choosing windowing environments that are specific to each platform. This approach allows you to create a user experience on each platform that isn't restricted by the compromises inherent to cross-platform windowing toolkits.

A good first step is to break your design down into two parts: platform specific and platform neutral elements. You can already put any UI code into the platform specific column, but maybe your app will need some data persistence that can be written in platform-neutral C++. What you may find with this approach is that there is quite a bit of logic and infrastructure that you can write in a platform-neutral way, leaving just the UI and glue code as platform-specific.

There was a recent episode of Late Night Cocoa titled Porting Large Applications to the Mac platform. Your app may not qualify as "large" but this podcast gives quite a bit of great porting knowledge from someone that's done it a few times.

Answer 4

I'm currently working on porting tools in this space and have many years of oft-painful experience in either using or writing cross-platform frameworks on Mac and Windows.

One of the biggest problems in the past has been Apple's refusal to open up the nib format for Cocoa (Carbon nibs were open XML files years ago). That changed with XCode 3 and the .xib format, as well explained by Frasier Speirs.

At the basic layout level, at least, there is now an opportunity to automate porting from one XML format to another. I regard WPF (XAML) as cleaner and so I'm using that as my base format and migrating to Cocoa.

When it comes to the code behind, whilst you can use C# under Mono, the CocoaSharp project seems either stalled or very slow and I wouldn't recommend it.

If you are comfortable with C++, consider having as much logic as possible in C++ with a thin platform-specific layer in C# and Objective-C.

Another approach worth investigating is using a dynamic language like Python or Ruby. I'm not sure which is more mature at present between IronPython and IronRuby but both are now supported by Microsoft people. On the Cocoa side, I think the flexibility of Ruby syntax will triumph and RubyCocoa is probably overtaking PyObjC.

Otherwise, work in C# and Objective-C and maintain two completely independent code bases with identical designs. Fortunately the frameworks have comparable semantics for most things, especially if you make use of bindings.