Hacker News new | comments | show | ask | jobs | submit login
Porting from Windows to Mac isn't easy (imvox.com)
42 points by tibbon 2711 days ago | hide | past | web | 32 comments | favorite

Quote from the posting: "But if you make a totally native UI you now have a lack of consistency between products. For games, this is less of an issue, but for a piece of desktop software your users notice either way."

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

As someone who works with Linux, Mac and Windows on a daily basis (Work is most Linux with some Windows, Mac for home) I have a very strong preference for native UIs.

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.

So true. That's why use Safari & Mail.app on OS X and before that, Konqueror & KMail on KDE. (They are great apps, too.)

One reason is so that your internal testers won't have wildly different experiences. It's much easier to verify one UI than several slightly different UIs.

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.

Thinking about your having to train your QA people as opposed to improving the experience of paying customers seems like the wrong way to go about it.

I'm of the school that your program should respect the conventions, style, and guidelines of the platform it is running on. Anything else is disrespectful of the user's buying decisions.

Yep, and that's what we've done. It was interesting to contrast what we have done (now) with Steam, where they went for pretty much the same look/feel that they've had on the Windows side. They do a pretty good job at it imho, but I'm not a UI person myself.

Well, it can be easy if you use the right tools and frameworks right from the beginning. When you are only using Microsoft specific tools, of course it will take a lot of work.

Using Visual Source Safe? Using .Net? Using .Net forms? Using MSVC? (And even now when developing for MacOSX??)

I think its a testament to their perseverance and skill that they were able to take such a legacy system and port it to the Mac. They used some pretty cool technologies (Mono, MonoObjC) along the way and solved the problem. This is a really good hack :)

Good job to the imvox team!

Edit: grammar.

Yeah congratulations to Mono and MonoObjC teams. This is great news for all those other business apps that are currently Windows / .NET only.

What is the right tool for cross platform work? Do any of the frameworks really generate a proper native-feeling OS X application? Or are they just "good enough"?

There aren't great cross-platform tools that provide good native-feeling results, mostly.

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.

That highly depends on the target. In case of games, I rarely see them using the native widgets anyway.

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.

python has done a great job at cross-platform development. If anything I'd say there is more work spent on "native-feel" in windows than mac. Since windows is the one that doesn't play well with others.

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

Absolutely. This is something we didn't realize from the get-go. A Mac version wasn't in the initial plan until we realized (aka, I came onboard) that we needed one.

And that's something that really bothers me.

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.

This appears to be a bit slow:


Summary: Using platform specific tools and languages results in lock in. Unsurprisingly. (See also: iPhone OS)

OUCH. I just checked my processor loads. Load average: 19.24 15.41 17.06 (single CPU on Amazon)

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 development is difficult. No way around that.

Use Squeak Smalltalk. Your program runs bit-identically across over 40 platforms. Done.

Cross platform is easy. Cross-platform with native look & feel - that's hard.

Or Java. Or QT. Either way, you end up with something that works terribly on all platforms.

Nope. Squeak Smalltalk works great across just about everything. (I assume you can work out the implications of "bit identical.") The UI is quite distinctly non-native on all of them though. Java can't hold a candle to Smalltalk for cross-platform.

> The UI is quite distinctly non-native on all of them though.

... which is what really matters to the end user.

You get no argument from me there. What about browser based apps? Those have a different set of user expectations. XUL desktop apps, anyone?

I'm not bashing Squeak here. I know it's a nice development environment. Problem is, people usually judge applications by their UIs. Look at it this way: a desktop application is supposed to complement the features your OS already ships with. An application that doesn't feel like it's a part of the OS confuses people. Heck, I'd say any app that doesn't follow native UI conventions is disrespecting the user, especially if it's a paid app.

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

I'm surprised not to see this in other comments, but RealBASIC is surprisingly awesome for cross-platform application development. It certainly has its limitations (BASIC), but you can crank out Linux, Windows, and Mac executables with nearly no OS-specific code.

The enterprise license is $1000, but it was worth it for my company.

Not necessarily. You just have to plan for it.

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.

Cross graphics-API (D3D to OGL) development is especially difficult.

It's nice to see the occasional reminder of this, among all the Web 2.0-ness around here :-)

A lot of apps still need to run in the Dark Ages that are desktop development, Balkanization and all.

This was also a major learning experience for me. I've mainly worked in Web 2.0-only companies that wouldn't dream of writing a desktop application. Everything is incredibly different from my PoV and many staples of modern web writing (functional tests, agile methodology, etc) can't be assumed in a desktop environment.

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

> (functional tests, agile methodology, etc) can't be assumed in a desktop environment.

Why not?

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

This is why I write web apps.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact