

Porting from Windows to Mac isn't easy - tibbon
http://imvox.com/blog/2010/05/pc-to-mac-ports-not-an-easy-process/

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

~~~
cubicle67
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.

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

------
albertzeyer
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??)

~~~
smackfu
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"?

~~~
angelbob
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.

------
bensummers
This appears to be a bit slow:

[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://imvox.com/blog/2010/05/pc-
to-mac-ports-not-an-easy-process/&hl=en&strip=1)

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

~~~
tibbon
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.

------
ryanpetrich
Cross platform development is difficult. No way around that.

~~~
stcredzero
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.

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

~~~
stcredzero
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.

~~~
GeneralMaximus
> _The UI is quite distinctly non-native on all of them though._

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

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

~~~
GeneralMaximus
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

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

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

~~~
bad_user
> _(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".

------
whyme
This is why I write web apps.

