Which approach to follow for developing applications targeting multiple platforms?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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...)

Answer 5

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!

Answer 6

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.

Answer 7

Leverage The Web!

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

Why?

• 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!

Answer 8

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.

Answer 9

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)

Answer 10

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

Answer 11

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.