Cross-platform development - Go with a cross-platform UI toolkit or native on multiple platforms?

Question

I'm looking for some arguments to pitch to my boss and fellow developers.

We're currently finishing up the preliminary UI mockups and getting ready to move on to the next phases of development. In the meantime, I've been digging through the depths of the Carbon, Win32, and wxWidgets APIs attempting to make some of the controls have a more native look and feel on the Mac and Windows platforms.

The more I dig into the Win32 and Carbon APIs to implement the things we want in our project's UI, the more antiquated they feel, and the more I'm beginning to think that we should be implementing the project as described in the last paragraph here.

We're using wxWidgets for our current projects. wxWidgets is coming along on the wxCocoa port, but it doesn't look like it's going to be ready for prime-time before we start major development efforts on our new application. On the Windows side of things, it wraps the Win32 API rather than WinForms or WPF (likely due to native vs. managed code).

We're already designing the system with the MVC pattern in mind, thus aside from having to write two native UIs, it should be very doable, and, IMHO, easier to get the desired UI effects using modern APIs such as Cocoa and WPF.

I've been trying to push these points subtly, but the start of major development is coming soon. Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?

Thanks in advance.

Answer 1

Personally, I'd rather stick multiplatform and don't give a damn for that eyecandy, but if I wanted to pitch the use of those native APIs, I'd work out the (end-user-visible) differences between how things are done in different GUIs. If you can convince them that, in order to feel native, the program's user interface has to look and feel very differently on Windows and OSX (because of different design guides/philosophies/whatever), they should understand that, even with wx, you would still have to implement it twice, to accommodate those different requirements, so you might just as well use the real thing, i.e. the native API.

Answer 2

Every time you add a layer of abstraction, you trade control over the details for more rapid development. You'll be able to get a lot done up-front using some cross-platform framework. On the flip side, when you want to do something that the framework doesn't support—and lets face it: it isn't going to implement all possible things those native APIs can do—you either have to implement it (for all platforms) using the native API, or do some other wierd hackery to get a "good enough" solution. And of course, when things go terribly wrong, having that extra layer of code you don't own makes it harder to debug. There really is something to be said for owning your entire stack as much as possible.

Answer 3

Also see this thread on the Google Chrome mailing list discussing the same choice of UI for Chrome on different platforms.

Answer 4

Actually I think using Qt has become very interesting since it's now LGPL

Answer 5

Win32 is definitely waay to old, but you might want to look into something like Microsoft Foundation Classes which is designed to do native development with C++. I assume that a similar thing exist for MAC.

Personally if I was in your situation I would properly also go for QT or WX.

Answer 6

Create your core code in Standard C++ and use Objective-C++ with Cocoa to create your user experience on the Mac and C++/CLI plus C# with WPF to create your user experience on Windows. Follow the platform guidelines for the Mac in your Mac version, for Windows in your Windows version, and don't even bother thinking about trying to share user interface code.

One good way to manage this is, instead of just Model-View-Controller, following a Model-Model Controller-View Controller-View architecture. Your Model Controllers are platform-independent and manage the higher-level functionality of your application. (For example, its entire concept of documents, file format, job queues, and so on.) Your View Controllers are platform-dependent and mediate between your Model Controllers and your user experience.

Of course you'll probably also want some platform-dependent code at the model level too; for example to use NSOperation on the Mac and thread pools on Windows to implement job queues. Just create your own lightweight abstractions for that sort of thing.

Answer 7

Writing two font ends is a lot of work, maintaining two front ends is a huge amount of work, if you need your program to run on multiple platforms go with a multi-platform toolkit.

If you write platform specific front-ends, each using the state of the art tools for that particular platform, you will get a much better user experience - but the cost of developing and maintaining those will be on the same order of magnitude as developing the entire application from scratch for each platform (yes, even with MVC).

Answer 8

Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?

No one likes a corridor-wiseass.

I think action speak louder than words...make a small prototype of how you think it could be done, and show it. Maybe you have to do this in your spare time.

Cocoa is really great so I think that with little code you can show an idea...well, this require that you know Cocoa enough.