Framework · Windows

Cross Platform Application

Louis Hatzis

July 12th, 2013

I want to develop a cross platform app for Windows and OSX. 
What road we I follow, Java, C++ or some other framework?

Keep in mind that later on there will be clients for IOS and Android.

Brent Goldstein

July 12th, 2013

Is there a reason it cannot be a web application? Client side web frameworks are getting very capable now. This gets past most of the platform specific issues beyond dealing with a few different browsers, which is easier now that it used to be. 


Alexander Ross Head of Business Development at Verifide

July 12th, 2013

I feel cross-platform stuff is currently a mess- no matter which path.I just spent a lot of time working on tools for all of the above plus we needed a SaaS/web version. We used AIR and Flash but be prepared to hear the "Flash is dead" phrase from the peanut gallery, including investors. You didn't mention the need for a web-based version so that makes Qt a possibility for you.

I agree with John that cross-platform UIs can cause problems but I don't think this is always the case. Some applications do lend themself to more standard native UIs but others do well with a custom look across platforms. Spotify uses embedded Chromium for cross-platform and web apps. This is an option too but a not a mature and proven path. Which means the safest assumption is there will be some engineering headaches in doing so.

Personally, I couldn't fathom actually trying to manage seperate code bases for: Windows, OSX, iOS, and Android. I can't help but think you'd spend more time coordinating than developing new features.

Last question- do you really need to be cross-platform? Sometimes it is better to nail it on one platform rather than spread resources. In my case, unfortunately, this was not an option.

In summary, I felt working across platforms (mobile and desktop) was a 'damned if you do, damned if you don't process.' Compared to the web development many of us are used to- writing one server version and tweaking for different browsers- it really seemed a pain to me.

John Wallace President at Apps Incorporated

July 12th, 2013

Don't take this approach. I invested a HUGE amount of time and money with a Java-desktop-based solution. I also looked at other approached (Air and Qt). When it was all said and done I would have invested a fraction of the money if I had taken a platform-native approach. The problem wasn't the underlying code. That part was beautiful. The problem is that each platform at the UI level has idiomatic differences. Macs and Windows look and feel different. Android and iOS look and feel different. We spent so much time making the code feel right for the platform (which our users absolutely demanded) that it would have been far cheaper for us to write the code for each platform. The other benefit of being platform native is that you can get to market faster, albeit without the full spectrum of targets. There are problems with the write-many-run-many approach, sure. But don't be seduced with the allure of finding a write-once-run-many solution. Biggest mistake I ever made. GIve me a shout. I'd be happy to let you know what worked and what didn't work for us.; 614-245-5445

Freeman Fan Entrepreneur

July 12th, 2013

You might want to look into Adobe Air.

Aaron Perrin Software Architect / Senior Developer

July 13th, 2013

Unless you have particular requirements that mandate a native app (performance, hardware, lack of network, etc.), you'd be better off going with a web app, as others have suggested.  Web deployments make things much more manageable, accessible, available, and modern.

If you choose to go web, I recommend developing an cross-platform API as part of the design.  That way you keep your options open for developing native, mobile, or particular web deployment styles (e.g. air).  Of course, your users may still require internet access!

Steve Banfield

July 12th, 2013

You can take a look at It will let you do cross platform Mac, Windows, iOS, etc but the underlying code needs to be written in C#. Depending on your development staff that may be a learning curve for them.

I haven't used it so I can't speak to how hard it is to develop with, or the potential performance impacts of using it vs doing native code.

Chipit Promotions Software Architect

July 12th, 2013

+1 for AIR

Jerome Dangu CTO & Co-Founder at ClarityAd

July 12th, 2013

+1 for Qt goodness.
WxWidgets and Gtk are other options. Java is possible too.
iOS and Android will require their own implementations.

Another way is to go full HTML, building the core client in HTML and light native wrappers (webview) for each platform. For desktop, Chromium Embedded Framework enables a similar concept as Webviews in mobile apps.

Matthew Szatmary Senior Video Encoding Engineer at Twitch.TV

July 12th, 2013

I have done this many times with great success using Qt.

Dimitry Rotstein Founder at Miranor

July 12th, 2013

Each language has a variety of associated cross-platform frameworks, and it's hard (if not impossible) to say which language has better frameworks. So first I'd choose a language based on other factors, and then decide on a suitable framework (not vice versa). For Java the best one I know is CodeNameOne, though it's not exactly mature yet, and I'm not sure it supports desktops at all. Eclipse is supposed to be cross-platform too, or so I've heard. For JavaScript there are PhoneGap and Appcelerator's Titanium. And for C++ there is Digia's Qt, which supports Win and OSX, and should support Android and iOS soon (if not already). Embarcadero's FireMonkey seems to be not bad as well (at least at a first glance - haven't really looked much at it) and it supports Delphi (for some reason) in addition to C++. There are a few dozen other frameworks I know of, but they all appear to be not worth the effort for one reason or another.