Hacker News Reader

Comment by nostrademons | Hacker News Reader

I would give up on "cross platform" desktop apps and use whatever the native language is for the platform. For Windows, that's C#/.NET. For Mac, Objective C/Cocoa. For Linux, probably C/Gtk or C++/Qt.

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.

View on HN

And it's not like Firefox or Eclipse (or Photoshop, to pick a commercial example) feels anything like a first-class citizen on the Macintosh. I'm not sure that there's much of a percentage in making cross-platform apps, really. The platform idioms and user expectations are just too different. Pick one platform and do a kick-ass job.

EDIT: Brain-fart: Firefox != Mozilla.

I agree with everything nostrademons is saying, cross platfrom apps are bad. I did some java desktop apps about 4 or 5 years ago and the ui was awful. i think it's gotten a little better... but still, native app is going to look far superior.

And that might even matter for some audiences. It doesn't for all of them: BCC had 2x the conversion for installations on Mac (where it is, ahem, distinctly non-native) relative to Windows.

u right patio11, bendmorris should really tell us who the target audience is.

Whether it matters depends a lot on how competitive the market is. If your app is head and shoulders above the competition in functionality, users will put up with a little UI ugliness. If most of the apps in your market basically do everything the user wants, they're going to decide based on what is prettiest/most responsive, which is usually the native app.

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.

Well, if Java means Swing, you are extrapolating from a very bad example. For instance, the Qt library looks pretty native on most platforms, and with some platform-specific code (e.g. proper support for application menus for OS X) Qt programs can also feel native.

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.

C++ with QT or wxWidgets is highly portable.

http://www.wxwidgets.org/

Maybe so, but it's still gonna stick out like a sore thumb everywhere. Meaning annoyed users, meaning the app is never ever gonna become a buzz on blogs and shit, meaning low earnings.

I have a counterexample which comes immediately to mind, but he wouldn't appreciate being mentioned. So, trust me on this one: uses QT, well-beloved by a traditionally underserved market, is "a buzz on blogs and shit" for that community, now has a boatloat of competitors, and doing "quite well indeed."

QT has a style system that can closely match the target platform.

So does Java Swing, but that never stopped Java from sticking out like a sore thumb everywhere.

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.

Maybe just a bad example, but the QT doc says:

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

http://doc.trolltech.com/4.7/qfiledialog.html

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

Does last.fm's desktop client stick out like a sore thumb everywhere?

On a Mac it sure does.

You make a good point with regards to the native look. Is this really done in practice, creating different versions of the same app to target different platforms? Not only would that require duplicating the code, but in my case I'm familiar with .NET and C++ but have never touched Objective C. It seems like it would make the most sense then to only target Windows, which is something I'm reluctant to do (I'm a Linux guy at heart.)

If I had to do a cross-platform app, I would make a shared core in a language that can run on all platforms[1] and than a native UI in whatever language/toolkit is used for the platform. This way, the only duplication that is needed is the UI. And honestly, cross-platform UI toolkits never quite fit in properly anyway.

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

Transmission follows this approach somewhat, it has Cocoa, Qt, Gtk+, Web, and console frontends. All frontends use a shared 'backend' in the form of libtransmission (in C).

http://www.transmissionbt.com/

Reply on news.ycombinator.com