The problem with cross-platform apps is that you end up programming to the least common denominator of the platforms you support, and your app never has the performance or look & feel that users expect. Contrast: uTorrent vs. Azureus, iChat vs. Pidgin, TextMate vs. jEdit, etc. In a hyper-competitive desktop space, that often means death. Giant companies like IBM (Eclipse) or Mozilla (Firefox) can get away with it because the scale of what they're doing is very difficult for a small startup to replicate, but most micro-ISVs can't.

Yes, this is one reason why developing desktop apps sucks.

EDIT: Brain-fart: Firefox != Mozilla.

I still remember discovering uTorrent. I'd tried about 4-5 Bittorrent apps before then, including 3 wxPython-based ones and Azureus. They also basically did what I needed - they let me download, they let me keep track of existing transfers, and they let me throttle bandwidth. The difference was that uTorrent didn't take up a few hundred megs of RAM and didn't peg my CPU. The developer accomplished this by doing an end-run around all the layers of abstraction and keeping an eye on performance; it's much harder to do this with a cross-platform library in the way.

I wrote some small Qt GUI applications (mostly frontends to scientific tools), and most people don't notice it's not native.

Also, this depends a bit on your market. Some markets are more sensitive to nativeness than others, for instance, by operating system:

OS X > Windows > Linux/UNIX

In OS X people are quite used to polished native applications that conform to Apple's HIG, they will also expect it. Windows is somewhere in the middle, there are some widely used applications that do not look native. Linux/UNIX users seem to be completely oblivious to nativeness, since they are used to having a mix of Qt/Gtk+/Tk/Lesstif/whatever applications.

http://www.wxwidgets.org/

Users become very sensitive to the details of the windowing system, and when a program breaks their expectations, they often consciously recognize what's wrong with the program, they just get frustrated. I'm thinking of things as subtle as whether you can create and rename folders from within a Save As... box, or what the tab order of fields in a dialog is, or what cursor shows up when you drag & drop items. It's very easy to get the look & feel 99% right and still have users feel that something is still very wrong with the app.

  On Windows, Mac OS X, KDE and GNOME, these static functions will call the native file dialog when possible.

QT is way better than Swing. It's a laughable comparison, really. QT does such a better job at being native.

1. I'd personally use C. But, thats only because I'm more comfortable in C than any other cross-platform language (C++, Java or any other JVM-based language, etc).

http://www.transmissionbt.com/

Thoughts on this at length are on my blog -- and if anything, a year later I believe everything here more strongly: http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-a...

With specific reference to decompiling your source code: it doesn't matter, because a) your application will be pirated anyhow and b) there is no difference to the end user the mechanism by which the pirated version works. Also, you shouldn't be worried about piracy unless you're selling to twenty-something white and Asian males, in which case piracy is one of many business-sinking problems you have. (If you're really worried about piracy, can I recommend web apps again, or at the least an integrated server component? Pirating the client lets you pirate the application like downloading Firefox lets you pirate Basecamp.)

Eclipse makes Java feel "dynamic" since it auto-compiles with every keystroke. Brilliant stuff, really.

Having said that, our server side will remain in 100% Common Lisp on the JVM. Since it's the part that sees near daily updates, unlike the client GUI which is code and forget.

My potential audience is pretty targeted - mainly research scientists and possibly some government workers. They'll likely be more computer savvy than the average user (on average, at least - some scientists I know are just as bad as Grandma.) What I worry about in considering a web app is:

1 - People want to be able to run the software anywhere, any time, without a connection to the internet.

2 - When entering large amounts of data, which is potentially sensitive, into an application, it seems like people would trust a desktop app more.

Number 2 is subjective, but as a scientist myself, I would feel better about a program running on my own machine.

Any thoughts?

However, since software doesn't rot and the BCC monthly server fees are mouse droppings even when it is going gangbusters, I could probably arrange for someone to support it for my entire natural life and beyond.

Given that and the lack of popular, high-level languages that compile to machine code (C++ is the best I can come up with), I'd reconsider whether that's really a priority.

I would prefer something like C++ which is about as obfuscated as you're going to get, but I'm curious if there are any higher level options that would save programming time.

- D

- Haskell

- OCaml

- Various Scheme/Common Lisp compilers

Some of them have Qt bindings (e.g. QtD and QtHaskell). Though it may be harder to hire programmers for any of these languages.

If you use Gtk for the GUI, it's cross platform using Mono. Lots of closed and open source widgets, easy to write your own, and runs very quickly.

IMHO, the networking stack in C# is much more robust and provides better performance than in Java, and you can static link the runtimes to the app, making deployment of installer-free apps relatively easy using embedded resources.

Cheers! Randy

.NET and Java are your best bets for relatively high-level desktop languages that are hard to decompile because since they're so widely used, obfuscation techniques are more advanced. But really if you want to create a difficult-to-decompile program, I think you're pretty much stuck with C or other non-interpreted, low-level languages (maybe try D?).

http://qt.nokia.com/

Dunno, a year off sounds nice, but you don't need to wait that long to be competitive. Better find a GUI and an obfuscation solution for a language you already know now, than to dick around with new languages when you have a product to finish and ship.

If I must. I would do the app in Python or whatever, then spend 2-3 weeks designing my own custom loader. Some C-based stub code packer that load a python interpreter as a shared library then my code. Wrap everything up with some compression and verify integrity with some crypto.

Nearly every embedded scripting language can be shoe-horned with custom packer like this that looks a lot like Java's ClassLoader. If you want to take this to its engineering extreme, you might even be able to get remote binary update functionality, by fetching packed tarballs of new code from your server, after the necessary key exchange.

[Edit:

Ok, I have started hacking something up as proof of concept. Leave an email in your profile or shoot me one.

]

It is really interesting that the gui problem still isn't solved after so many years. Personally i think microsoft made the right thing by really decoupling design from code. I'm not using windows tough...

Can anyone comment on the quality of the GTk+ bindings, or the existence of any other bindings?

I have enough experience with GTk+ from C and Python to say that it creates really nice, snappy UIs under Linux, but it's really hard to make it "feel right" under Windows, and pretty much impossible to make it "feel right" under OS X. On those platforms, it will almost always stand out the same way that Java apps do.

I'll also say that Haskell, while awesome, is a PITA to learn.

Yes, monads can be hard to get in the beginning, but they never felt like tricking the compiler to me.

Air

Python + QT

I just removed Air yesterday, and Appcelerator needs a bit more work.

Appcelerator I'm less certain on, but they do seem to keep tossing effort at things.

If you are going to use GTK+, take a look at Vala [1]. It's a C#-like language which is compiled into C. Much saner than coding in C. You can easily port your app to Windows/OSX, but, as others noted, non-native UI will be far from perfect.

I'm using this approach in an open-source project of mine [2], feel free to borrow the ideas.

[1] http://live.gnome.org/Vala

[2] http://www.spek-project.org/