For applications targeting multiple platforms, I see mainly two development approaches-

  • Go for some JAVA-like development platform. Have one code solution and let the intermediate runtime handle different platforms. If something goes wrong in any platform, tweak the code a bit. But keep it same for all.

  • Make modular code separating core logic and UI. Develop separate UIs for respective platforms which will be calling same core libraries. Build the application separately for each of the target platforms.

So, which one to follow? I know, the answer will start with "It depends". But I want to hear your opinions on these approaches and the factors to be considered to choose any of them.

  • 2
    As for this question, there is no way to answer it without using "it depends". It depends on so many factors, like what actual platforms you have in mind, are you planning stand-alone desktop application or planning to use some web services, what are your plans for the UI (the same for every platform or varied?) and so on. Do you think Qt or Gtk development model falls for first model or not? What about .Net and Mono? Shall I continue...? Commented Oct 30, 2010 at 17:04
  • @Gulshan Sorry, obvious question - is there a reason this can't be a web application and/or done w/ something like Adobe Air? Commented Nov 15, 2010 at 6:42
  • This site is more for subjective questions and answers, but so can reasons for acceptance. It just makes us feel like you're playing along. I tend to look for recently posted questions and not the unanswered.
    – JeffO
    Commented Nov 17, 2010 at 1:26

11 Answers 11


Current Oracle/Apache/Google squabbles aside, it's still hard to beat the JVM for this purpose. It's really very high quality on most platforms, universal, and you have a good number of languages to choose from (Java, Clojure, Scala etc.). It lets you target a single machine architecture (the VM), and not worry too much about the specific end-user hardware.

That said, there are certain application types it may not be as suitable for: low-level networking comes to mind, as does heavy graphics/video processing.


Go for HTML5. Any platform with a HTML5 browser can run your application. Although HTML5 is not ready for big time yet, the Web application approach is.

  • 2
    There are no feature complete HTML5 browsers.
    – Craig
    Commented Nov 13, 2010 at 7:51

In the Audacity sound editor we use wxWidgets as our cross platform library. Since we need to link to C libraries, and we need speed and low level access a JVM approach would not work for us. The GUI code is 95% the same on all platforms. We use #ifdefs for the small variations. However, we find it essential to have a developer working on each of the three platforms (Mac, Windows Linux), because even using the cross platform library it is too easy for a change on one machine to break things on another.

If you can get the performance you need, go for JVM. If you can't, use QT or wxWidgets, and I would suggest QT over wxWidgets since it is less work to get it to look nice.

  • 1
    +1 for "essential to have a developer working on each platform". Cross-platform projects quickly become single platform if you only develop for one platform at a time.
    – AShelly
    Commented Nov 17, 2010 at 0:21

As a real-time developer, I've successfully used an option similar to 2 - separate platform-specific modules with a common API used by the core logic. However, nothing I've done has had a UI - networking, audio, data streaming - in this case it is the low-level hardware interface that is platform specific.

I've done it this way for several reasons:

1) To get the optimum performance on each platform

2) To take advantage of features only offered on 1 platform

3) (J)VMs did not exist for some of the platforms (embedded systems, game consoles...)


It depends on what is important to you :)

When we faced this choice for a cross-platform Mac/Windows app about 10 years ago, we had a good look around the various cross-platform options - Java, Qt, wxWidgets etc. The problem we had was that the look and feel of the UI was really important to us, and all of the "cross-platform" apps looked, well, compromised. We ended up biting the bullet and building up our own cross-platform core, with a custom UI for each platform on top (written in PowerPlant for Mac and MFC on Windows). Over time we have got pretty good at this, and the "cross-platform" part has got thicker without compromising the UI.

We're now looking at this decision again for a new project. Looking at the options now, I would probably go with Qt - it's free and really seems to have matured nicely. Java might have been an option but we can't really take the performance hit (we're doing 3D image processing).

If UI is really important to you, I suspect you are going to have to invest quite a lot of time getting things looking right on each platform whether you use something like Qt or roll your own. For an internal or specialist app where users might be more accepting of a less polished UI, it might be fine!


Everyone makes a big fuss about languages like Java being "cross platform" but what they are really talking about is that you can compile once and run everywhere. Even in a language like Java (or C#/mono) you are going to still need abstraction layers to deal with OS specific details in some areas.

C++, and in fact most languages, are cross platform, you just have to compile to target each platform.

They key is the process rather than the tools/languages:

  1. Make sure you have an integrated build process that builds and runs the unit tests for all target platforms.
  2. Make sure every developer tests on all target platforms before checking in code - This obviously means making sure ever developer has access to the appropriate number of machines/vms.
  3. Abstract well. Abstract everything that calls into native apis. Write libraries that wrap these calls.
  4. If you are doing anything beyond fairly simple forms UI that just caters to the lowest common denominator, just accept that GUI code is not cross platform. Abstract your GUI/presentation layer out and code it separately for each platform. Yes there are cross platform GUI toolkits, which are fine for straight forward apps but if you are doing anything more advanced you will want to code to the native platform capabilities.

These steps are the same no matter what language/toolset/framework you use.


Leverage The Web!

Seriously, if you want THE most bang for your buck, write a web application.


  • Web clients don't require much PC power typically.
  • Web clients are EVERYWHERE. Not just PC/MAC/Linux, but on phones, mobile devices, and more.
  • Nothing extra to download for users! (Typically, unless you want something fancy and use Flash, or Silverlight)
  • All common components are on the server side, and can be Java, .NET, PHP, or a hodgepodge of a bunch of existing components you have. The client shouldn't care!

Even the two approaches you mentioned are very similar. The web browser renders HTML for multiple underlying architectures. Similarly, the JVM interprets Java code in a way that makes sense for the underlying hardware. The web, however, simply has a broader client base!


I've had pretty good luck with Mono. I can write the same code for windows machines as I do for Linux machines, and for the most part, it works on both. And I can use the skills I already know in C# and Winforms.

  • What UI do you use, or do you mean for server-based apps? I am curious because I have a working app using Winforms, and I've ported to Mono and it's nice, but would take a HUGE amount of work to be like the "real" winforms. Perhaps GTK# is better? MonoDevelop is nice, but perhaps a bit clunky. Commented Nov 2, 2010 at 5:51
  • With Mono both approaches can be followed. Like Yar, which one are you following and why? That is the question.
    – Gulshan
    Commented Nov 2, 2010 at 6:16
  • Yeah, I didn't realize you were looking for perfect form fidelity between platforms. You might get that with GTK#, but you will get it at the expense of "pretty," because a common toolkit like that has to go for the "lowest common denominator." I'm inclined to agree with StartClass0830: HTML5 would be a lot of work, but you could do some really cool cross-platform things with it. Commented Nov 3, 2010 at 2:49

Do a proof of concept first.

If it's a reasonably complex application, nailing out a proof of concept is going to give you an idea of what language features you need and what areas you're going to need to leverage framework or third-party libraries.

The language features and libraries you need are going to determine what language you'll end up choosing (and thus, how you'll go about approaching cross-platform support)


I built a system, starting with a desktop app, 15 years ago when Java was still in its infancy and not ready for use in building these kinds of apps. I knew I needed to have a core in C++ and designed it from the start to be cross platform, including using sized types (eg int32 instead of int or long), so it could run on Mac, Windows, and UNIX (pre-Linux days).

At the time I tried to look for a good cross-platform UI environment, there were a few then including XVT. I went through the training for XVT and when I started to build a real app, I realized that I wasn't going to be able to create a clean, native look and feel on the platform (starting with the Mac). So I gave up that idea and built a native Mac (PowerPlant) UI on top of the portable core.

A couple of years later, we moved onto Windows (UI in MFC). It was faster building a UI the second time around, we maintained a Mac and Windows UI in parallel for a short time and then went all over to Windows. The core later moved onto various flavors of UNIX and Linux, to allow us to run server-based computations. The core did port well, with some adjustments when we made it 64-bit ready.

Now I am back to using a Mac and I wish we could come back to the Mac, but the size and complexity of the app makes this a hard choice. It still makes sense for much of this app to be a desktop app - it is like a CAD environment. But rather than building the UI again in a platform-specific C/C++ language (and continue to maintain an MFC-based UI), I am more inclined to rewrite the entire stack in Java so it can run on multiple platforms.

There may still be reasons to run a non-Java core, say C++ as we did. But I would be wanting to run early performance tests to see if that was really required. And I would be looking carefully at my UI to see if I could be building it as a web app, connected to the core via web services, so I could have a range of clients - desktop apps, mobile apps, web apps, etc. If I needed a piece in C or C++, could it be written under a layer of Java? Or as a web service?

Another consideration - how long will your app be around? How complex will it grow to be? If you have any ideas about this, consider the possible longevity of any UI libraries you are using and your ability over time to have people help maintain them. This may be hard to consider now but worth a thought.

-- Alex

  • The JVM has proven to be very stable in terms of the runtime library backwards compatability. For this scenario it would have been a very well fit...
    – user1249
    Commented Nov 15, 2010 at 7:59

If you can make it a web app, make it a web app. Using toolkits like ExtJS, it's relatively easy to make good looking GUI-like cross-browser compatible user interfaces.

Otherwise, Java or QT+C++ or C+Wx are possible options to have one source for all.

Your second approach is appropriate if you want the app to look and feel native on every target platform. Native Mac apps look and feel different than native Windows apps, just using another skin and keybinds will not be enough to cover that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.