Why do you need cross-platform consistency? Most users use either Mac or Windows port, not both. Instead, focus on consistency _inside_ the platform: give the Mac port "macish" look, because that's what typical Mac user wants – elegant, clutter-free UI.
For example, Skype for Mac is pretty nice, while Skype for Windows is ugly as hell (from Mac user's point of view, Windows user may disagree).
My brain seems to have no problem at all switching between the 3 OSs, and remembering all the conventions, shortcuts etc, but I find it's the cross-platform apps that trip me up and cause the most frustration. Why? Because they look sort of native, but they don't work native. Shortcuts are different, menus are different, buttons use different conventions (OK/Cancel in the wrong order), OS specific features don't work (like Cmd Ctrl D) etc.
For me, the idea "But if you make a totally native UI you now have a lack of consistency between products." is a trap, and that the opposite holds true; lack of consistency is good as it tells your brain how that app should behave, but cross-platform consistency is bad as it sends wrong or confusing messages about what to expect re app behaviour.
This is similar to the cross-platform user experience, but even companies with very few cross-platform users will usually have a testing department, and have to worry about educating them with the product. 2, 3 or more different interfaces will add a lot to the burden of educating new QA folks.
Using Visual Source Safe?
Using .Net? Using .Net forms?
Using MSVC? (And even now when developing for MacOSX??)
Good job to the imvox team!
There are a number of cross-platform toolkits. GTK+, Qt and wxWindows all come to mind as possibilities. But in general, you're going to need to rewrite a lot of the front end as native code if you want it to feel like native code.
However, if you know you may be porting, you can separate a lot of the back end out of your UI code and make it a separate library in separate files. That makes it much, much easier to write several different front ends and still share most of your code.
Otherwise it depends. Right of the box you will at least get "good enough" (with Qt for example). If you want to support OSX-only stuff, of course you need some tweaks and platform dependend code.
I'd also recommend wxWidgets or QT using the related python (or ruby) bindings.
I know exactly what you are saying about "good enough" apps. I can still remember some gtk+ apps for windows a few years ago... it was embarrassing. Given enough time the apps I've seen recently are native and no longer just "good enough".
In the company I work for, there are web applications that are not even cross-browser.
I have to boot into Windows every month or so to do some bureaucratic work on them.
Summary: Using platform specific tools and languages results in lock in. Unsurprisingly. (See also: iPhone OS)
Something is wrong. Or HN is a ton more traffic than I expected. Normally sits fairly low. Figuring this out now. Thanks for the heads up.
update 1: The problem seems to be our git server (which of course we have running on this EC2 instance as well) is doing a git-pack way too often. Trying to kill or back this off. Tomorrow I'm moving it to another server.
update 2: Console-kit-daemon was eating a ton of memory. Git was playing its part, but not the real problem. I also took the time to tune mysql and apache a bit more as to more properly use the CPU/memory. We haven't had a traffic rush like that before. Thank god it wasn't Digg or something like that.
Cross platform is easy. Cross-platform with native look & feel - that's hard.
... which is what really matters to the end user.
On non-Windows platforms, XUL apps suck. Period. As for webapps, I don't think anyone expects them to look native. The rules don't apply inside that browser window :p
The enterprise license is $1000, but it was worth it for my company.
You will, of course, have some duplication - unless your cross platform means "Linux and BSD", your user interface code will be very different. You will have also to map all the platform dependent parts and prepare to cut your application along those lines.
It's more work, but, in the end, your app will probably have a better design than if you targeted a single platform. The better design will show when you have to upgrade it or to add another platform to the mix.
A lot of apps still need to run in the Dark Ages that are desktop development, Balkanization and all.
I also had to get used to having less data about how our consumers use our product. I'm used to being able to ninja through apache logs and Google Analytics to figure stuff out, but our data is much more limited from our analytics package.
Finally, finding killer developers to do desktop stuff is much harder than finding a Ruby or Python programmer. You're looking for people with specific expertise with somewhat strange problems that your average web programmer just isn't suited to handle such as memory leaks (I say this as someone who can hack in Ruby but I fail miserably at any desktop programming).
> You're looking for people with specific expertise with somewhat strange problems that your average web programmer just isn't suited to handle such as memory leaks
There are many apps out there that are suitable to be desktop programs. That specific expertise you're talking about is probably being unafraid to do stuff people want, instead of just another Twitter clone.
> I say this as someone who can hack in Ruby
The term "hack" is certainly overused recently. It used to mean something on the borderline of being illegal, or some artful workaround that's done in the interest of cutting corners, or some mindbogglingly experiment (like the Tesla Coil).
Not it's just related to meaning plain-old (and boring) programming. I blame the popularity of PG's essays for that ... yeah, we all want to be "hackers".