Advice for supporting both Mac and Windows Desktops

Question

What are the best practices for building a GUI desktop app that will support both Windows and OS X? Let's say it's budgeting software, so there is a bit of math and some big data structures. User data is saved in XML files; there is no separate database or networking.

At one extreme, you could just build the Windows version in C# and the Mac version in Objective C. Is there a better approach, so you can more easily keep the two versions in sync and write less duplicate code? Would you write the math and data structures and "business logic" in C++, with pre-processor directives for simple system calls like IO, and then a separate GUI layer written once for Windows and once for OS X? Is C/C++ the only choice for the cross-platform back end, assuming you want native code? Is there any way to write even the GUI part a single time? (I expect not.)

Please note that I'm not asking how to use a cross-compiler. I'm interested in how you'd structure your overall project for the least hassle.

Answer 1

It's very likely that I have a different view from most on this issue, given my strong feelings about platform native user interfaces and controls/widgets, but I very much tend to prefer your second approach. Even I'm not masochistic enough to go through the hassle of building the entire application separately.

So I would definitely write the library or data layer code entirely separate from the GUI layer. Doing it in C++ is an obvious choice, especially if you're already comfortable with that language, but more on that later. The point is that this code should be limited only to your "business logic", and thus completely platform independent. If you follow solid object-oriented principles, it should work out that the bulk of the programming work is done on this level.

Separately from that, you would write a thin, "wrapper" library over the core OS and UI functions for both Windows and OS X. The wrapper library would be the sole entity responsible for directly interacting with the platform, and your data layer code should call functions from this wrapper library, rather than directly from the platform's API.

Of course, several of you reading this are probably screaming "But that's what QT already does for you!" Yeah, I know. But it doesn't use native widgets, and it doesn't conform to standard platform conventions in so many places. That means it sucks. I've seen other wrapper libraries for Windows that do get this right, but I've yet to see one on OS X that looked halfway decent. Yes, I'm picky, but so is your typical Mac user. They just won't put up with the type of garbage on their screen that Windows users will, and even the Mac Office team knows this. (We all collectively applaud you for trying to get this right.)

As far as your choice of languages, you say that you are looking for native code on both platforms. That's a pretty difficult blob of jelly to pin to the wall. For example, do you consider JIT-complied code to be native? If not, that rules out C#. Excluding any type of interpreted code rules out a host of other potential languages. You aren't left with many options other than C++ and Objective-C. But C++/Win32 programming isn't that much more difficult than Cocoa programming, just different.

Answer 2

You are essentially correct. You would write the data model in C/C++ and the UI in C#/.NET and Objective-C/Cocoa.

I'm not familiar with how C# talks to non-C# code, but Objective-C (being built on C) will easily talk to C and C++ (the latter with Objective-C++). You can also use Python and/or Ruby with Objective-C code and the Cocoa frameworks, if you'd prefer to use them for the cross-platform segments.

I applaud you for looking beyond the easy solution of Java or other cross-platform UIs. You'll have a better-looking, easier-to-use product if you go the native route.

Answer 3

Have you looked at Mono? It allows you to develop in .Net but deploy across platforms.