Entirely agreed. My pet whinge about Firefox has always been that it's not a real Mac application and that it simply caters to the lowest common denominator, i.e. Windows. I'm not bothered that much about the appearance of the browser but what irks me is that it doesn't support those features than any good Mac (i.e. Cocoa) application does, such as using the network settings set in System Preferences, storing passwords in Keychain and checking my spelling using the Dictionary that I've already configured. As a mobile user it drives me bonkers that I have to change my network settings directly within the browser whereas all my other applications don't need to be touched in order to work within a different network.

Inter-operability is marvellous but it needs to be done right for the target platforms and not just for the lowest common denominator.

Well sometimes your clients want to have portable desktop applications, so I think that maybe not *everyone* want cross-platform apps, but *some* do. Then you must find a compromise, and make things as simple as possible, both for you and for your client.

An approach that I found useful for creating cross-platform applications with native UIs, is to create the backend in C++ (that is, the core of your application), use Interface Builder & Cocoa for the UI, and then use Objective-C++ for binding both. Typically the only objc class will be the controller, and the rest is your C++ code. Of course you lose several features built in Cocoa... but you get portability. It's a tradeoff.

This way you have a portable application core, that you can compile in different platforms, and you provide a Mac app with a pure, native look & feel. For the Windows XP and Linux ports, I found that wxWidgets is a fine choice, since it provides a decent UI in both environments. But not for Mac, since you cannot achieve the same degree of design and style; Cocoa is ahead of everything.

For the C++ part, a nice portable library that provides lots of functionality with a portable code base is POCO (http://www.appinf.com/poco/info/index.html). This helps keeping the core of the application portable, and with CppUnit you can unit test it extensively without much effort, in several platforms at once.

This approach, of course, might not be always possible, but in some small projects of mine it gave me great results.

Just my 2 cents! :)

Adri

I agree. I always thought that each computing platform deserves to have its own unique style of user interface. The Mac needs extra attention because of the amazing technologies you can leverage by creating a Cocoa app.
But the Mac isn't the only platform that deserves special treatment. I am currently in the process of developing a multiplaform application, but I have decided that it would be worth my while to write separate and unique implementations for not only Mac OS X, but for Windows Vista, Windows XP, and Gnome. Each platform is unique and has its own set of UI guidelines.

I completely agree. Mac users want things to be Mac-y. It's an innate sense that we get about applications. Even the lay Mac user can tell when something "feels" at home on the platform. When crossing platforms, developers really ought to embrace all the platform has to offer for its application, even if it means tweaking the interface slightly.

Scott, I whole-heartedly agree. And for me, it's the little things that I tend to notice about an app that sways me or not on it's use.

Case in point: In Camino and Safari, if you want to quickly save a website, but don't want to bookmark it (or store it on del.icio.us) all you have to do is drag the sites favicon to the dock and a little @ symbol appears. Not so with Firefox (or Flock for that matter). Drag to the Dock NEVER works. You can drag to the Desktop, but not the Dock. That fact right there has been one of the big factors of why I DON'T use Firefox. Mozilla just didn't pay attention to the little things.....

Statement:

People use these cross-platform GUI libraries to make development faster, and I don't think this is such a bad thing. The reason apps written using these libraries tend not to catch on on the Mac, is that they aren't Mac-like. That said, they do tend to catch on on Linux and Windows.

I am willing to bet this is due to the fact that the Windows and Linux GUI shells are nearly identical.

Question:
Why arent't there* any cross-platform GUI libraries that attempt to bring a Mac-like interface to other platforms?

* there might be, I just have never heard of any.

I definitely agree. I think the days of maintaining a unified codebase for multiple platforms are becoming numbered. There is so much more benefit to developing desktop applications to specifically target the OS for which they are being written. Beyond just look and feel, you get the slightly more intangible but exceedingly rewarding benefit of integration. One of the things Apple seemed to really be emphasizing at last year's WWDC was building apps that integrate with the whole Mac experience. I, at least, feel that one of the most important goals of developing a Mac application is to make it feel like an extension of the entire user experience, rather than an individual, self-centric, and marginalized entity.

GNUstep. That is all.

It has become somewhat of a habit, that when I find an application which basic idea I find nice, but its UI sucks, I go over to Hyperjeffs OS X software list (http://osx.hyperjeff.net/Apps/) and do a search for Cocoa apps that do the same or have a similar feature set.

If I look for an app that does something I need, I by default start looking for Cocoa apps and only if I don't find anything there, I grudgingly start looking for other apps (Carbon, too is all too often not OS X like).

I don't really agree. You can build apps with cross-platform tools that provide a similar - if not identical - user experience as Cocoa apps. It's just that most cross-platform developers don't have much experience with Mac OS X.

It just takes some effort and knowledge of all platforms you're deploying on..

@Lieven: You can build apps with cross-platform tools that provide a similar - if not identical - user experience as Cocoa apps

How is this possible given Cocoa and related framework provide functionality which don't have counterparts in cross-platform toolkits? Core Animation is one obvious case. AppleScript, Spotlight, and QTKit are others.

Interestingly enough, I was recently rereading Tog on Interface, published way back in 1992, where he made the exact same point. Many companies assume that they can go through the following three stages (I am paraphrasing here, of course):

1. Make a direct port of their app, with no attempt to be Mac-like.
2. Glue a few Mac features on top of the port.
3. Use the $$$ raised from selling 1 & 2 to do a native Mac version.

Unfortunately, most apps that try that die somewhere in stages one or two, because Mac users want to use Mac Apps. Not ports. I do cross-platform software development (Windows, Linux, and Solaris (would like to get it ported to Mac, but there is no management support at this time)), and I really hate Linux programs that try to pretend to be Windows, or to be Mac (though this is far less common). Be native. Help me bear in mind what platform I am on by the subconscious cues that platform-specific behaviours give me.

Statement:

People use these cross-platform GUI libraries to make development faster, and I don't think this is such a bad thing. The reason apps written using these libraries tend not to catch on on the Mac, is that they aren't Mac-like. That said, they do tend to catch on on Linux and Windows.

I am willing to bet this is due to the fact that the Windows and Linux GUI shells are nearly identical.

Question:
Why arent't there* any cross-platform GUI libraries that attempt to bring a Mac-like interface to other platforms?

* there might be, I just have never heard of any.

A great browser, but Safari is far more popular on the Mac because it's designed for a Mac user.

Isn't that like saying Internet is more popular on Windows PC because it's designed for a Windows user? It's the installed browser and if people are just going to "surf the web", they don't need much more. I think a more logical explanation is that Safari is more popular because it's included with the operating system and is "good enough" for most users.

To really understand if cross platform apps like Firefox are being accepted, you need to understand the percentage of users on each platform are using that app. Unfortunately I can't find many stats broken down by platform, but Mac360 did an analysis of it's visitors 2 years ago and found that 20% of it's readers were using Firefox. Since it's a Mac site, you can safely assume that the majority of the users are running Macs.

@Ben: I think a more logical explanation is that Safari is more popular because it's included with the operating system and is "good enough" for most users
I think Safari would probably still win, but I agree it's an imperfect example. It was just a covenient one to explain the point. I also think the fact that Camino exists as it does supports the premise. I was tempted to compare GIMP and Photoshop, but that's tricky for different reasons.

@leeg: GNUstep. That is all.
I'm aware of GNUstep (I actually designed the site), but it's not what most people think. It has a common ancestor with Cocoa, and it picked up some of the newer classes, but they're nowhere near interchangeable. Not to mention a Mac app is defined by much more than just AppKit, Foundation and Core Data.

@David Cairns: That said, they do tend to catch on on Linux and Windows. I am willing to bet this is due to the fact that the Windows and Linux GUI shells are nearly identical.
I think there's a lot to be said for that, and maybe some folks are thinking that, by extension, if you just swap in the appropriate widgets you have an app Mac users will like. It's just not true.

I totally agree about Firefox vs. Camino/Safari. Firefox is not a Mac application, and I avoid it for that reason. I prefer Safari, and when I need Gecko, I use Camino. But a Mac application needs to support Mac features and that means a) Keychain, b) address book, c) proper drag and drop, d) proper Aqua-widgets, etc.

I know some people don't care about this or like that Firefox is the same on all platforms, but I'm not using all platforms - I'm using a Mac and for a reason. So, why would I use an App that really isn't a Mac app?

Your point usually holds, but I think there are exceptions. A notable recent one is Adobe's Lightroom: It is cross-platform and looks essentially identical on MacOS X and Windows. Yet it doesn't feel particularly "foreign" on either platform. It doesn't feel particularly "native" either, but I think it strikes a very nice balance by having its own personality dominate without really clashing with its host OS's culture.

I thought it worthwhile to check the stats from the past two weeks of Google Analytics on Mac360 regarding Firefox Mac vs. Firefox Windows.

At a high level, just under 50-percent of all browser visits to the site use Safari (all Mac users, of course), just over 26% use Firefox (Mac and Windows), and 18% use MSIE (Windows only).

At a more granular level, about 40% of all Firefox visitors to the site are on a Mac. The rest of the Firefox users are purely on Windows PCs. We presume that many of the PC using visitors are "captive" Mac users. Mac users by night (home), MSIE users by day (at work). From this, it's a bit difficult to determine from our numbers whether Mac users truly don't like using a cross-platform application that is not "Mac like" as is the case with Firefox, however, the stats favor a Mac experience such as Safari.

Camino comes in with a healthy 3% of browser usage, though the more Windows-like Opera is barely 1%.

Timothy: Tog on Interface is a classic. I'm surprised to learn it's in print -- I thought it had gone out a while back, and was slightly sad at the time.

This 'straight PC ports suck' thing used to be common knowledge. Guy Kawasaki talks about it in his circa 1991 'The Macintosh Way.'

Real Mac software, the software you come to the platform to use, has always been designed specifically for the Mac, using Mac conventions and Mac culture. This was as true in 1986 (when the alternative was frequently a bad DOS port, like Microsoft Basic) as it is today, even though both Windows and Macintosh have evolved.

Linux and Windows users tend to be more tolerant, probably because they're used to lower standards. This situation is improving on Linux. I haven't tried Vista yet, but I can tell you that it's not going to fix 20 years of bad third-party software UI.

I'm not sure I agree with the Cocoa interface purity (or snobbery, depending on your point of view) that I'm seeing here. I spend all day using a wide mix of programs on my Mac, and while I prefer those that provide a better "Mac user experience," I'd say only a minority of the apps I use are Cocoa. Here are the apps that I spend the majority of my time in:

Office X
NeoOffice
Aquamacs
IDLE
Terminal
Dreamweaver
InDesign
Safari
Mail.app
Thunderbird
Firefox
Vienna
Gimp.app
Inkscape
Preview
Acrobat

Seven Carbon apps, four Cocoa apps (only one of which is a third-party/non-Apple app), a Java/Aqua port of an X11 app, and two X11 apps deployed as standalone app bundles.

I'd say that the common denominator of all of these apps (even the X11 ones) is that they try to provide a good Mac user experience--and they succeed, in my opinion. NeoOffice is better than OpenOffice in this regard, for instance (though even OpenOffice is now deployed as a standalone app bundle with an AppleScript stub launcher). I simply don't think Cocoa is essential to providing a good user experience; understanding the HIG *is* essential. (I use a cross-platform toolkit--Tcl/Tk--to develop Mac-only applications, so I have some understanding of this issue.)

The thing that makes me crazy about obvious ports is all the hidden features built into Cocoa (and most Carbon) apps that stop working. Simple example: in a text box with only one line, hit the down arrow. In any well-done, Mac-conistent app, the cursor will go to the end of the line. This has been the case for about 2 decades. Not so with Windows (and Linux, which seems to mimic many bad choices of Windows) - the down arrow does nothing. The Mac seems to say, "Well, I cannot go down, so I might as well get as close to that as I can." Windows says "Duh. Cannot perform that function" and ignores what you probably want.

Firefox uses the Windows/Linux behavior, on a Mac. Of course, Microsoft Office for Mac does, too.

This is just one simple example, but every time I use a non-Mac-like piece of software, I find myself being held back by all the little behaviors that just don't work. Then again, iTunes and other Apple programs sometimes run into similar problems. Even more disconcerting when that happens.

@Kevin Walzer: I'm not sure I agree with the Cocoa interface purity (or snobbery, depending on your point of view) that I'm seeing here
I was painting with broad strokes mentioning Cocoa. I didn't at all mean to say that Carbon apps can't provide a real Mac experience. Final Cut Pro is very much a real Mac app, and certainly it is based on Carbon. Really the point of the post is the nature of cross-platform development, not Cococa or Carbon.

Seven Carbon apps, four Cocoa apps..., a Java/Aqua port of an X11 app, and two X11 apps deployed as standalone app bundles
I count five Cocoa apps: Safari, Mail, Terminal, Vienna and Preview. For what it's worth.

Honestly, I really don't care if it's written in Cocoa or Carbon if the experience is pleasing. The point of this thread is what new developers should look at. In most cases, the best bet is a Cocoa-centric UI layer which can optionally call into existing "business logic" C and C++ libraries.

I simply don't think Cocoa is essential to providing a good user experience; understanding the HIG *is* essential
I don't know if you need to understand the wording of the guidelines specifically, but certainly the ideas that they describe. In a sense, I think it's also just as important to know when to go outside of what they suggest.

Whew. Scott, thanks for steering us away from the Carbon vs. Cocoa debate yet again.

I have recently worked on 2 cross-platform applications, both of which had a core C++ base. The difference was whether the Mac UI was an afterthought or not.

In the first, it was Mac Carbon and Windows MFC from the start, but we evolved the UI to Cocoa on the Mac side and .NET on the Windows side, with almost everything directly below the UI in cross-platform C++. This takes a bit of planning and coordination (not to mention experts on both platforms), but is absolutely the right way to approach development because you are thinking about the whole of both platforms at the same time, and you have the flexibility to embrace Mac conventions and technologies.

In the second project, I started with an MFC Windows app that was several years old and which was not really going to change. I ended up re-implementing my own subset of MFC and Win32 in Cocoa so that I could maintain compatibility with the Windows code, while still being able to go in with NIBs and tweak the UI. While it had many advantages over a pure cross-platform framework, some parts of the Cocoa UI were still driven from Windows code, so weird artifacts and usability problems will poke through.

Yes of course you can make non Cocoa apps for OS X that feel very "OS-X-y", but I for example need my apps to be able to handle Japanese and German Umlauts at the same time, and since many programmers just seem to completely forget about internationalization of their apps (I'm happy enough if the Umlauts don't get mangled) this is often the point where most non Cocoa apps become useless for me, because the programmer simply has to make an effort to make Unicode work there, and most of them just don't bother.

With Cocoa Unicode support is par for the course (there are exceptions, very bad ones...). Apart from that I know many non Cocoa apps that try to look like good OS X "citizens", but very few of them really can convince. Also all of the Cocoa goodness you get more or less "for free", the programmer needs to make quite an effort to support in other frameworks, like Services (which I use a lot), spell checking etc. And then there are the very handy tools which many Cocoa delopers use to add functionality like LinkBack or Sparkle. Which just make everything even more seamless.

Scott: (GNUstep) has a common ancestor with Cocoa, and it picked up some of the newer classes, but they're nowhere near interchangeable.

For a lot of work they are; a large subset of Foundation code, AppKit code and NIB files can be used on both platforms. GNUstep then has some extensions to the Foundation/base library, which are available for both GNUstep and Cocoa. No KVO yet (so no bindings), but we're hoping to change that.

My comment was actually aimed at the question: Why arent't there* any cross-platform GUI libraries that attempt to bring a Mac-like interface to other platforms? GNUstep is even a Mac-like framework for cross-platform development. It can be themed to provide a Mac-like interface (see étoilé), though note that due to the software patents which I'm sure everyone here loves, it would be illegal in the US to mimic some of the OS X behaviour due to their acquisition of NeXT's patent portfolio. Lines connecting target and action across multiple windows in IB, I'm looking at you.

@Scott: How is this possible given Cocoa and related framework provide functionality which don't have counterparts in cross-platform toolkits? Core Animation is one obvious case. AppleScript, Spotlight, and QTKit are others.

Not all applications need or even benifit from all these technologies. If you absolutely need one of these, there's no doubt about it, Cocoa will be pretty much the only way to create your application.

But while for instance Core Animation is cool and pretty easy to do great stuff with, it's still possible to do equivalent stuff with other toolkits. It will require more work and attention to detail though, which is what I meant with It just takes some effort. The obvious benifit is that the application can be deployed on other operating systems too. The obvious downside is that integrating with the operating systems you're deploying takes more time.

@Kevin Walzer
I'm not sure I agree with the Cocoa interface purity (or snobbery, depending on your point of view) that I'm seeing here.

Call it snobbery if you like, but most of those apps on your list are painful to look at and use on a Mac. If you compare them to OS-X-native equivalents, the result is terrible bloody-noses for the cross-platform app. The contests aren't even really close.

Office X, NeoOffice:
Office X was among Microsoft's buggiest releases. 2004 is better but still pretty bad. And OpenOffice/NeoOffice? Give me a break. They're like poor imitations of the buggy MS app, with more bugginess tossed in on the side. These apps don't even really try to fit in: they don't integrate with OS X tools like the keychain, or services, or keyboard conventions. My Cocoa key bindings won't work in them. They are a drag to use in just about every way, and the only thing they have going for them is format-compatibility with a Windows product. If you compare with Mellel, the two word processors are pretty pitiful. Keynote beats Power Point hands down. And it's very sad that Excel is the only real spreadsheet app available on the Mac.

Aquamacs, IDLE:
These both completely ignore proper Mac behavior. Emacs is extremely powerful, but designed for a text-based terminal, and doesn't take advantage of any of the last 20 years of UI improvements. It doesn't interact well with other programs on the system, and is only really usable if you plan on staying full-time in emacs and never coming out again.

IDLE finally has a decent icon (designed by me!), and they finally got around to making most of the menu keyboard shortcuts conform to Mac standards (yay!), but I wouldn't really recommend it to friends at this point. It's great to have a free GUI editor ship with the mac python distribution, because it gives new users a place to go first, but it would take a lot of work to polish it up to the point of power-user-friendliness.

Try out TextMate, and you'll see what a well-planned, well-implemented Mac text editor can be, at its best. It beats both of these two hands down, in my opinion.

Thunderbird, Firefox:
The only reason I use thunderbird for mailing lists is it does proper threading. The only conceivable reason to use Firefox over Camino is the extensions. If you compare to Mail and Safari, which are also on your list, Thunderbird and Firefox both get stomped on. I really like Camino, but OmniWeb is also nice. I've thought of switching to OmniWeb before, but inertia keeps me with Camino.

Dreamweaver, InDesign, Acrobat:
I don't really like Dreamweaver's cognitive model (preferring to just use TextMate), but all three of these have good corporate support, and are well made. They have more in common with other Macadobe apps than with normal Mac or PC apps, so I wouldn't really call them windows ports. Acrobat (and Acrobat reader) is getting a lot more decent as time goes on.

Gimp.app, Inkscape:
I'm happy that people are working on open-source image processing and creation tools, but these really don't hold a candle to Photoshop/Illustrator. Between lacking features, UI wonkiness, and just general poor UI planning, I w0uldn't use either of these unless no other option was available. No professional users (or anyone who really pushes the boundaries) is going to be using these two any time soon, and I don't see the UI improving radically if no one who needs the improvements is using these apps and complaining about their limitations.

Vienna:
I use this one too, because I have very simple RSS needs. But I don't pretend to think it compares in quality to NNW.

Terminal, Safari, Mail.app, Preview:
Interestingly, I think Apple could do a lot better with all of these. Mail needs real threading, good IMAP support, some assurance that emails won't just disappear, and some improvements to its smart mailboxing/tagging/searching aspect. Preview is still feature-limited compared to Acrobat Reader. Safari should really drop the brushed metal, because it's truly ugly, and add incremental search and bookmark keywords while they're at it (only reasons I use Camino). And I can think of plenty of ways to improve Terminal.

But what they do do, these apps do quite well. They aren't as fully-featured as I'd like, but they at least aren't horribly buggy beyond belief w.r.t. UI.

----

What I get from your list is not that you like cross-platform apps, but that you like free apps, and are unwilling to pay for any software, unless it's produced by a major corporation like Microsoft, Adobe, or Macromedia (maybe you get those through school, or from anonymous internet friends?). That's fine, but you shouldn't kid yourself that the apps you're using are better, just because they don't cost money.

@ David Cairns:

regarding your question "Why arent't there* any cross-platform GUI libraries that attempt to bring a Mac-like interface to other platforms?", you might want to take a look at JUCE, a C++ cross-platform GUI library that provides a very nice answer to this problem.

http://www.rawmaterialsoftware.com/juce/

I think that may be a good general principle: the only way to make a really good application is to use it yourself, and most of the people who make free/open source software are hackers, not artists, or office workers, or photographers, or movie producers, or DJs, or motivational speakers, or whatever.

So what ends up happening is that the professionals in those fields go out and buy the best app they can, because it improves their productivity, and they can easily earn back the price. Those pros really push the apps to their limits, and they talk back to the software companies about what they like and don't.

On the other hand, the things software hackers really push to their limits are things like web browsers (which everyone needs, and hackers, having more internet time than most, and requiring quick information lookups online, etc. really use a lot), text editors (for obvious reasons), web servers, core development frameworks, etc. The only GUI tool most hackers really need is a web browser. For most other things, emacs/mutt/remind/whatever in a terminal is sufficient.

So what happens is that the F/OSS hackers really put a lot of energy and effort into those hacker-centric tools, or at least the sheer quantity of interested hackers overwhelms, and those types of open-source apps get improved quickly. That's why Linux, Python, Emacs, and Firefox are all really great.

On the other hand, for photo/movie/sound editing software, presentation software, apps which integrate with all the super-expensive tools like high-definition RAW-taking cameras, high-end audio gear, etc., and are used to push non-hacker limits, the corporate software just blows away the offerings from free software developers. This makes sense: the F/OSS guys are doing it as a weekend project, while Adobe and Apple and other corporate developers are making lots of cash selling software, and have large teams of well-paid engineers. The side project guys, many of whom are using linux, don't have the time or energy to make Mac native apps, or even to really do adequate Mac testing, oftentimes. So when their software has buggy, nonstandard behavior, it's not really a surprise.

@Jacob Rus:

Call it snobbery if you like, but most of those apps on your list are painful to look at and use on a Mac. If you compare them to OS-X-native equivalents, the result is terrible bloody-noses for the cross-platform app. The contests aren't even really close.

OK, I will call it snobbery. And your response is too long to go through line-by-line, but I will address as much of it as I can.

Office X, NeoOffice:
Office X was among Microsoft's buggiest releases. 2004 is better but still pretty bad. And OpenOffice/NeoOffice? Give me a break. They're like poor imitations of the buggy MS app, with more bugginess tossed in on the side. These apps don't even really try to fit in: they don't integrate with OS X tools like the keychain, or services, or keyboard conventions. My Cocoa key bindings won't work in them. They are a drag to use in just about every way, and the only thing they have going for them is format-compatibility with a Windows product.

I use Word because I grew up with it (on both Mac and Windows). I use OpenOffice/NeoOffice (I've standardized on it for my book publishing business, in fact) precisely because it is cross-platform and most of the people I work with in my business use Windows. And while I agree with you about the X11 version of OpenOffice, NeoOffice works great (albeit slowly): Command-F is the keyboard shortcut for text search, it supports Mac fonts natively, it has a standard Mac menubar, and supports Mac printing natively. It is also superior to MS Office in some ways: it has a very decent, built-in vector art tool that is good for cover design; and it has superb PDF export, out of the box. It's not just because it's free, although that's a consideration (especially for requiring my partners to standardize on it); the more important thing is its feature set meets my needs better.

Aquamacs, IDLE:
These both completely ignore proper Mac behavior. Emacs is extremely powerful, but designed for a text-based terminal, and doesn't take advantage of any of the last 20 years of UI improvements. It doesn't interact well with other programs on the system, and is only really usable if you plan on staying full-time in emacs and never coming out again.

IDLE finally has a decent icon (designed by me!), and they finally got around to making most of the menu keyboard shortcuts conform to Mac standards (yay!), but I wouldn't really recommend it to friends at this point. It's great to have a free GUI editor ship with the mac python distribution, because it gives new users a place to go first, but it would take a lot of work to polish it up to the point of power-user-friendliness.

Disclosure: I was one of the original developers on Aquamacs (http:://aquamacs.org), so I'm not objective. But if you think it's standard Emacs, you're misinformed. Aquamacs implements as many standard Mac UI functions as is practical. The clipboard works in a Mac-like way; you can search your files for a string with Command-F and Command-G, just like in any other Mac. It also has standard Mac help (accessed via Help Viewer).

Great job on the IDLE icon! IDLE is much improved in Python 2.5. I use it for my Python development; it's perfectly adequate for my needs.

Try out TextMate, and you'll see what a well-planned, well-implemented Mac text editor can be, at its best. It beats both of these two hands down, in my opinion.

TextMate doesn't have support for one of my primary development languages (Tcl) out of the box; you have to install a third-party package. I'll gladly do that with open source software, but not with a commercial text editor; it should have what I need from the start. Aquamacs has much better support for Tcl built in, and the Mac customizations to standard Emacs mean that Aquamacs is reasonably close to TextMate in Mac ease-of-use.

Thunderbird, Firefox:
The only reason I use thunderbird for mailing lists is it does proper threading. The only conceivable reason to use Firefox over Camino is the extensions. If you compare to Mail and Safari, which are also on your list, Thunderbird and Firefox both get stomped on. I really like Camino, but OmniWeb is also nice. I've thought of switching to OmniWeb before, but inertia keeps me with Camino.

Thunderbird has good support for NNTP, and so I use it for my developer e-mail. Its newsreader is superior to any of the commercial alternatives on the Mac (except perhaps for Unison, which I haven't tried). I use Firefox because a) it accesses some sites better than Safari does, and b) I like having a second web browser. Camino isn't as snappy or polished in my experience as Firefox.


Gimp.app, Inkscape:
I'm happy that people are working on open-source image processing and creation tools, but these really don't hold a candle to Photoshop/Illustrator. Between lacking features, UI wonkiness, and just general poor UI planning, I w0uldn't use either of these unless no other option was available. No professional users (or anyone who really pushes the boundaries) is going to be using these two any time soon, and I don't see the UI improving radically if no one who needs the improvements is using these apps and complaining about their limitations.

My needs in these areas are pretty lightweight, so these applications are adequate for me.


What I get from your list is not that you like cross-platform apps, but that you like free apps, and are unwilling to pay for any software, unless it's produced by a major corporation like Microsoft, Adobe, or Macromedia (maybe you get those through school, or from anonymous internet friends?). That's fine, but you shouldn't kid yourself that the apps you're using are better, just because they don't cost money.

I don't take kindly to your assumptions. I'm a 38-year-old small business owner (publishing and software development). My selection of software tools is a decision of strategic importance, as it affects my productivity and also may require sizable capital investment. Whether it's a commercial or a free application, my choices are carefully considered. As I've said, I consider OpenOffice to be superior to MS Office because of its PDF support and integrated vector art tools, and I consider Aquamacs to be superior to TextMate because of its Tcl support. On the other hand, I've purchased Dreamweaver because it's better than the alternatives for website management and design; I've also purchased commercial icon sets/design for the software I develop because the free alternatives were inadequate.

Getting back to the point of the thread, I don't disagree that adhering to Mac user interface conventions is critical; I try to do this as much as possible in my own applications. My apps are built on cross-platform toolkits, but make extensive use of platform-specific extensions; also, their design would make them look weird on other platforms (assuming they ran at all). And I also agree that small, independent developers are competing on the basis of the user experience they provide, more than the features of the applications they provide. But within the broad parameters of the HIG, the "user experience" is often a matter of taste. As an end user, I don't make much use of Services, so applications supporting this don't impress me. And, in fact, I find some highly-praised Mac Cocoa applications (such as Adium) unintuitive to use; the fact they are free is not enough to entice me to use them.

My impression is you mix here different stuff. You can not compare Safari with freeware programmers Firefox.

Compare SPSS, Kaleidagraph, Inspiration as example with the counterparts on the Window side.

There is no question that for OS X at the moment no high end IDE is available - I mean something which cost at least 15'000 USD. Xcode is OK but not for large applications.

Filemaker is as popular at the Windows front like on the Mac. The market share increased year by year at least with 30 %.

A browser is compared with Photoshop a very small project. I wait at the moment when XCode is as stable and efficent like Powerbuilder on NeXT/Openstep.
I have every kind of app. Apple only, mixed ones, Everything.

The only thing which counts is high-end quality. That's the main reason Omnigroup is out of my list except the Outliner.
Aabel stats on the other side I wish to see at the Windows front. It's a very remarkable piece of software.
High end pricing is one of the reason to drop Filemaker for Openbase/Frontbase/Sybase.
Cheap software is a waste of time and energy.

@Kevin Walzer
TextMate doesn't have support for one of my primary development languages (Tcl) out of the box; you have to install a third-party package. I'll gladly do that with open source software, but not with a commercial text editor; it should have what I need from the start. Aquamacs has much better support for Tcl built in, and the Mac customizations to standard Emacs mean that Aquamacs is reasonably close to TextMate in Mac ease-of-use.

Well, if by "third-party package", you mean downloading the language bundle from the community-and-developer-supported subversion repository, I suppose that's true. But such is the case for any language besides the top dozen or two. There simply isn't room (in the download or in the UI) to include every one of the 100+ languages in the svn repository "out-of-the-box", though installing new ones takes only about 2 minutes. All of these bundles are open-source, so I'm not sure what the concern is on that front.

Disclosure: I was one of the original developers on Aquamacs (http:://aquamacs.org), so I'm not objective. But if you think it's standard Emacs, you're misinformed. Aquamacs implements as many standard Mac UI functions as is practical. The clipboard works in a Mac-like way; you can search your files for a string with Command-F and Command-G, just like in any other Mac. It also has standard Mac help (accessed via Help Viewer).

Well, I certainly can't expect the author of Aquamacs to switch text editors any time soon, and I can understand that editors are a very personal choice, in which cross-platform availability, and decades of familiarity weigh very heavily. But IMO it's not really possible to integrate Emacs into the OS X interface, in the same way that can be done with an application designed for the Mac, and for that matter, designed for a GUI. Wrapping a GUI shell around it doesn't really change that.

Thunderbird has good support for NNTP, and so I use it for my developer e-mail. Its newsreader is superior to any of the commercial alternatives on the Mac (except perhaps for Unison, which I haven't tried).

Yes, this is true, and as I mentioned, I use TBird for mailing lists and nntp as well, because it does proper threading, and that is the most important feature for such uses. But its buggy and inconsistent interface constantly bothers me, particularly the anemic text fields, which are vastly inferior to Cocoa text fields.

I use Firefox because a) it accesses some sites better than Safari does, and b) I like having a second web browser. Camino isn't as snappy or polished in my experience as Firefox.

Hmm. Everyone I've ever heard compare the two has found Camino faster, so I'm surprised you find the opposite. And w.r.t. polish, there's really no comparison. Camino's widgets (text boxes, buttons, sliders, etc.) are more Mac-like, and less glitchy, than Firefox's, though that should be improving in Firefox 3, as they switch Firefox to using Aqua widgets. So I guess I just have to disagree on both your points here.


I don't take kindly to your assumptions.

I apologize. It was improper of me to make such a suggestion, and I retract it. You certainly have the right to use whatever software works for you, even including un-Maclike apps, or apps that I find too buggy to be usable for me. I find many college students I know use about the same set of applications you do, because they can get the $200+ apps for free, through school, but balk at paying for $30-50 shareware apps, and so use freeware for the rest.

But within the broad parameters of the HIG, the "user experience" is often a matter of taste.

Okay, but applications like Gimp.app, Microsoft Office, Firefox, IDLE, etc. don't really come close (some don't even try) to following the spirit or letter of the HIG. They look and behave out-of-place on a Mac, and as a Mac user, I prefer more Mac-like alternatives.

----

Anyway, I'm not trying to flame you, or your preferences. They are completely legitimate for any number of reasons, such as cost, feature-set, experience, or cross-platform availability. I just don't think fitting in well with the system can be one of those reasons, as at least to me, most of those apps stick out like sore thumbs.

One so-called "rationale" for non-Mac like interfaces is UI consistency across platforms. This is a lame excuse. I not infrequently move between applications every few minutes. I rarely move between platforms more than a few times per day. If I'm going to do a UI context switch, I'd rather do it when crossing platforms (where it is bleedingly obvious which mode I'm in and was accompanied by physically changing location) than when crossing apps on a single platform.

I disagree.

Firstly, cross platform apps are the only reason the Mac still exists. Without Photoshop, Illustrator, Acrobat, InDesign, Word, Excel, Flash and the like, the Mac would have petered into non-existence - or at least total irrelevancy - years ago. (You could argue that Linux has grown without any of those; however it is an open source system whose success was built on open source apps - basically it's foundation for success has been low cost. But, if those apps came to Linux, it would kick Windows off the planet.)

So to say "The thing is Mac users just don't want cross-platform apps." is incorrect. They might not care if say a SuperDuper or a Adium or a NetNewswire is cross platform or not, but apps that are significant in the Windows world, they do want. Consider the push *still* for AudtoCAD to go cross platform. In the business world, Macs would greatly benfit form Visio and Project coming across.

Secondly, Firefox is not a good example. No open source cross platform apps spring to mind that are ideal Mac citizens. It is just par for the course. So that argument should be taken up with the whole open source development community. You'd be better off using the example of a traditional and successful Windows app that has made the transition, but failed to Mac-ify as good as it should.

Thirdly, your statements seem to change from talking about Mac developers not wanting to develop cross platform apps (which I'd agree with) to the opposite direction of development, that is "Bringing an application across from Windows". But I suspect your article is really about the former, i.e., if Macs developers develop for cross-platform, they might either have to lose features in the Win version, or sacrifice them on both.

Fourthly (sorry for these adding up!), with the trend towards web-based applications, we will see the diminishment of the OS influencing the design of an app. In some cases, I'm seeing this as wonderful thing, with designer/developers producing some great interface innovations, although there are some bad examples too.

Lastly, I run a site that promotes cross form apps - CrossOSS and I've been really surprised by the depth and breadth of cross platform development. There is a lot more cross platform apps out there, and development than we realize.

Without Photoshop, Illustrator, Acrobat, InDesign, Word, Excel, Flash and the like, the Mac would have petered into non-existence
I agree, but this list is misleading. Word and Excel are not cross-platform apps. They have the same brand name but they're different code bases than the Windows version. Photoshop and Illustrator were designed for the Mac to begin with, so I think you possibly have to strike those. InDesign is largely based on ideas from Photoshop and Illustrator, so that too is a special case. That leaves Flash but that could be a whole separate discussion. In any case, a cross platform app may succeed if it provides a unique service and there are no "native" alternatives.

So to say "The thing is Mac users just don't want cross-platform apps." is incorrect.
Maybe I could have worded it better. By cross-platform I meant an app that uses a cross platform toolkit for the higher levels instead of native views and such. Of course, yes, Mac users want Visio and AutoCAD, but they version which are designed for the Mac. From what I've seen, Skype is a good example of a port done right. In general, Office takes the right approach as well, though they have a very delicate line to walk between Windows feature parity and Mac sensibilities.

Secondly, Firefox is not a good example. No open source cross platform apps spring to mind that are ideal Mac citizens [...] So that argument should be taken up with the whole open source development community
I don't think it has anything to do with open source. Vienna and Adium are open source applications but they provide a good Mac experience. Camino, in fact, is open source. I'm sure the Mac Firefox developers do the best they can, but it's probably a policy/priority issue. I think Mozilla sees Firefox more as a platform than a series apps tuned for each OS, but I might be wrong.

Thirdly, your statements seem to change from talking about Mac developers not wanting to develop cross platform apps
I re-read what I wrote but I can't find any instance where I intentionally said this. Maybe something was misinterpreted?

I suspect your article is really about the former, i.e., if Macs developers develop for cross-platform, they might either have to lose features in the Win version, or sacrifice them on both.
No, that was not my intention. I suspect Mac developers know about the unique APIs available to them. The point was to help incoming developers from other platforms understand that a "cheap" port just won't fly.

with the trend towards web-based applications, we will see the diminishment of the OS influencing the design of an app
Certainly email and productivity apps can work well on the web, but there are many kinds of apps that just aren't as suited to that sort of client/server model. It's not clear to me how something Final Cut Pro or Aperture would fair considering the need for real-time processing and some very large blobs of data. You need local apps to interact with local devices such as cameras, DVD burners and iPods. The question is whether you want all your productivity apps running in a separate environment from your local apps. Personally, I think you can sacrifice a lot of convenience and usability by doing so.

Allow me to chime in here. I don't know squat about programming, but in my experience it's the cocoa apps I like to use, and it's the carbon apps I don't like to use. I can usually spot a carbon app immediately even if I don't look for clues. They tend to just look off and feel wrong. The only app that has ever fooled me in this regard is Intaglio which I assumed was cocoa, but is really carbon. This is a well done carbon app. The rest? Can't stand them.

Incidentally, I had a chance to try out Photoshop CS3 the other day. I know that some major twiddling was done to get it running on Intel — something about porting it to XCode — but while I have to assume that it's still a carbon app, it actually looks and feels a lot nicer than CS2 did. I'm not sure why, but I noticed it immediately. It feels more like a Mac app now. On the other hand, its new installer looks decidedly Windows-esque, and that's sad. Why they can't just make it a drag-and-drop deal is a mystery and a bummer.

The point was to help incoming developers from other platforms understand that a "cheap" port just won't fly.

On that, you certainly get no argument from me!

Thanks too for the clarifications, I see now the point of your piece about using cross-platform development kit, as opposed to developing cross platform for each platform's strengths and features.

And again I agree. Most of the former, esp those done in Java, leave me cold.

One app that does spring to mind now, and that looks and works great on Windows and OS X and uses a some sort of CPDK, is ArtRage. However, it has developed its own unique GUI which is neither Windows nor OS X. But it works coz it's so dang hot!

One app that does spring to mind now, and that looks and works great on Windows and OS X and uses a some sort of CPDK, is ArtRage
I agree. Excellent piece of software.

One design pattern that is essential to cocoa, but really to all good apps is Model-View-Controller, right? I think the confusion here is in the differences of these three aspects.

Model is the back end and the least impacted of the three. Barring something like Core Data, a good crossplatform's app can have this identical across systems.

View is the opposite, the most obvious of the three, but the most fixable. Slap in a nib file, apply that aqua-y filter on the images, etc. Pretty pretty screen shots.

The slippery slope is Controller. To a degree this can be cross platform, but too much and it becomes obvious. This is the true measure of how well behaved a mac program is. I haven't used Neooffice, so I don't know how maclike it truely is. Perhaps this is the litmus test:

1987: Command F, cut copy paste. All vintage System 6. Meeting just this means you're 20 years behind the time.

1997: Drag and drop. Mac truetype fonts. PDF support. Help menu. Welcome to MacOS 8. 10 years behind the time.

2007: Contextual menus doing fancy things like spell-checking. Services. Sheets. Dock icon alerts and badges. Spotlight support. These are the earmarks of a modern mac app.

Obviously, not all of them are necessary, but a few are sufficient. What makes some of us chafe at firefox isn't its rendering and network engine; to the contrary, that's its saving grace on the mac, a good model.

What makes some of us chafe at firefox isn't the windows or scroll bars. They use standard graphics, the view.

When I reread the complaints, it's all about what's between. The controller code. And that is all the difference.

@Blain: View is the opposite, the most obvious of the three, but the most fixable. Slap in a nib file, apply that aqua-y filter on the images, etc.
Wouldn't it be great if it was that easy? This is part of the puzzle, but there's really a lot to it.

What makes some of us chafe at firefox isn't the windows or scroll bars. They use standard graphics, the view.
That's true to some degree. In some cases, though, applications will use controls that look like standard Mac controls but they don't act like them. Or maybe they just look similar, rather than the same. Do they implement accessibility protocols, or what happens if the user increases the screen resolution?

The MVC design pattern is certainly a big factor, but there are a lot of implementation details that go into a good piece of software. It's not necessarily just the controllers or just the views. But of course there are things to consider in each.

apps that are significant in the Windows world, they (=Mac users) do want

Adobe and almost all of their products used to be first and foremost Apple Macintosh apps, Macromedia started out as Macromind selling Director as their one an only app. Macromind Director was Mac only. (Same is actually true for Word and Excel BTW).

These apps might be the big mainstream apps on Windows now as well, but that is irrelevant for their wide acceptance with Mac users. Adobe apps are relevant to Mac users, because almost all of the pros using and needing Adobe apps have been on the Mac to begin with. Photoshop is THE standard in design, because of the Mac and the fact that just about all designers were on Macs. This has changed in recent years a bit, though.

Same counts for Macromedia. Multimedia was just such and utter pain in the a** do create on Windows for many years that it was mostly done on the Mac for long time. This is what established Macromedia as the default in MM. The Mac and the designers using it made those two companies big. And once these apps became quasi standards, because of their wide use by pros, then home (many of them Windows) users started pirating the software and made those apps ubiquitious. Some of those people eventually ending up buying the apps.