JUST KIDDING. Quite the opposite in fact. It's been really exhausting porting stuff to OS X. Here are some reasons why:

1) Poor (and often hard to find) documentation-- Yes, some of the newer APIs are decently documented, but dig in and try to use ATSU to render text, and it's a world of pain. Looking through header files that all seem to assume you know what to do. This is tolerable, though, with enough digging you can find what you want.

2) The AudioUnits SDK-- the API for AudioUnits is defined in a header, but not documented. So to use AU, you'd have to either just use the SDK (with EXTENSIVE amounts of code), or reverse engineer it to figure out what calls you need to do to control the plug-ins yourself. Someone obviously spent a lot of time defining an extensible plug-in API, why the fuck don't they document it?! I mean, really, just a "first, call this, then, call that, then, when you're ready to process X, do Y." If this info is somewhere, someone please let me know... (see the next point)

3) The previous two points might to be related to the fact that Apple seems to assume that as a Mac developer, I've been developing for macs continuously since 1984, and have religiously read the developer mailing list since whenever it was created. Apple: for the love of god find some way of getting those mailing list posts linked to/from the relevant documentation pages.

4) There are WAY too many ways to accomplish similar things. The classic example which I bitch about a lot is text rendering--last I checked, there is CoreText (apparently awesome, but 10.5 only), CoreGraphics text functions (seem nice, but lots of limitations including non-functioning text measuring), HITheme rendering (which is nice but doesnt give you much for font style selection), AppKit NSString/NSAttributedString drawing (great, but slow), ATSUI (seems to be the best all around but takes a bit to get to the point where you get what's going on). I understand that there are historical reasons for these APIs, but again, this can be fixed with proper documentation (perhaps a page describing all of the APIs and their benefits and drawbacks).

5) Addition of new APIs in new OS versions. I know Apple wants to sell new OS versions, but from a developers standpoint, it's really difficult to properly support multiple versions of OS X. I'd like to use new OS features if available, but fall back to old versions if not. If there's a clean way to do this, I'd love to hear about it -- on Windows we usually just load the appropriate DLLs if available..

6) Performance on OS X for basic graphics drawing seems terrible. Perhaps if you take advantage of the highly OS X specific stuff, you can get around some of this, but as an example I made two native projects, one for OS X and one for Win32, that create a 640x480 window and try to draw at about 30fps. They fill the background black and draw white lines. On Windows basic double buffering is used, on OS X the system buffers the drawing. The OS X version uses Cocoa and CoreGraphics to draw, and the view is opaque.

The source code which you can build is here (VC6/win and Xcode2.4+ for OS X required).

Results: on the same Core2 hardware: OS X: 11% CPU use. WinXP: 1% CPU use. In fairness to OS X, it was drawing pretty antialiased lines, however when I disabled AA on the OS X build, the CPU use went _UP_ to 20%. Go figure. It's not really the line drawing, either--make it draw just one line the numbers dont change much...

Well I don't have anything to really bitch about Windows right now, but I'm really disappointed with all of the VC++ builds after VC6. The issues are a plenty, but it makes it hard to upgrade. All dynamic linking uses msvcrt71.dll etc which even MS doesnt distribute anymore, so you end up having to static link. Bleh.

I guess most people don't care about the size of their software, but for us keeping the program size down is also part of keeping the development process fast and efficient. If I have to upload a 30mb installer and everybody has to download one to test...