Create a cross platform Windows, Mac OS X applicat

Question

I would like to build an application that runs on both Windows and Mac OS X. I would also like it to leverage the best of what the platform it runs on has to offer with regards to Frameworks, API's etc. Is there a way to do this without having to write Objective-C code and then C# code? I've been thinking of C++ as an alternative but I was wondering if there was anything else out there. The app will be GUI based (though I don't know exactly what it will do yet)

-G.

Answer 1

Java or Mono come to my mind. Some people may argue that java graphical toolkits are not the cuttest out there but it seems to be, at least to me, the easiest way to port your application to several platforms and avoid deployment difficulties.

Mono, on the other hand, could be a little bit more difficult to port as you would have to write at least the gui twice if you plan to have native widgets (either winforms or GTK for windows and CocoaSharp for Max) but you could write the backend only once and develop a frontend for each platform.

As I said, Java GUI toolkits might not feel "native" inside OSX or even on Windows but they sure work on both platforms, you could use either Swing or AWT.

As for mono, you can use GTK or Winforms for both windows and OSX but they still will not feel native, you can, however use CocoaSharp which are bindings to the Cocoa framework but Im not sure about the status of the project (read: functionality support)

Answer 2

As long as you are not tied to languages, it looks like Java is a good candidate. Pair that up with SWT for the GUI, and you will have a native looking app on any OS you like.

Answer 3

For completeness, it's now worth adding Unity to the list.

It would be very hard to create a native-looking app for either platform and the general GUI tools are far from mature. But, it's not just a game engine and you can write in C#/Mono, make use of a decent range of libs and deploy to Win and OSX fairly painlessly.

Answer 4

If you're a Windows developer, use either Qt or C# Winforms; if you're a Mac developer, you could try Cocotron (http://www.cocotron.org/), but it's not 100% finished yet, though commercial apps have been shipped with it.

Answer 5

It's good that you're thinking of portability early on - it's vastly more difficult to "bolt it on" after the fact.

There are various cross-platform kits available, but IMHO all of them fall a bit short of providing a "native" look and feel on all the supported platforms. On the Mac (what I use), proponents of such kits always want to mention that they're using native controls. That's a good start, but it's not the whole journey. Other issues addressed by Apple's Human Interface Guidelines include how the controls should be arranged, how button labels should be phrased, what standard shortcut keys should be used, etc.

Even Microsoft had to learn the hard way about the dangers of trying to write a cross-platform GUI, with the ill-fated Word 6.0 for Mac.

IMHO, a better approach is to use an MVC design, with the model layer written in standard, portable C++, and the view and controller layers using the native toolkit for each platform. For the Mac version, Carbon and C++ throughout used to be an interesting option that is now not supported anymore, so you would want to use Cocoa, using Objective-C in the view and Objective-C++ in your controllers to bridge the language gap. Your Windows version could likewise compile your model as "managed C++", and use any .NET language for controllers and views.

Answer 6

If you do decide to go with C++ there are a number of good cross-platform GUI libraries that will allow you to avoid having to duplicate the GUI code for each platform. For example:

• Juce
• QT
• wxWidgets

There are a number of other similar projects but those are some of the better and more well-known ones. For the remainder of your code, anything system-specific will of course have to be written using separate C++ code to interface with Win32 APIs or OS X's system API where necessary. That being said, you may find you're able to avoid much of the system-specific code by using extensive libraries like Boost.

Other suggestions would be things like using a configuration file instead of the Windows registry or a plist file on the mac. Instead, shoot for platform-agnostic approaches wherever possible to minimize the places where you have to write code using system APIs.