Developing on the Mac - A Windows Developer’s Perspective

Good post here by Mac switcher Russell Beattie who isn’t entirely ecstatic with his switch. Some of his points I take lightly as he’s flogging his own company’s Mac alternatives (Konfabulator), but I agree with many of his sentiments.

I bought a Mac Mini back in the spring, mainly to play around with and/or port games to, but with the off-hand thought that if I really liked it, I’d buy a heavier duty Mac and make a full switch. I found it initially interesting, but not compelling. Now, after not using it for a while, I spent some time over the last few weeks porting my nearly complete casual game to the Mac, and am somewhat more negative on the Mac. Following Beattie’s lead, here’s some random kvetching:

1) X-Code

Most commercial Windows developers use Microsoft Visual Studio to make their programs. It’s a great program, but it costs about $700. On the surface, Apple’s development system X-Code, looks shiny and new and nice, and its free. But given how much Apple likes to charge for stuff that should be free, developers should be wary of their software that should cost money but is in fact free.

X-Code is a bad software development tool. Its unstable, confusing, and hard-to-use. When I changed the name of my current project from Writer’s Block to Bonnie’s Bookstore, it took me about 3 hours of hunting, compiling and things breaking before I found all the obscure nooks and crannies in which X-Code had hidden references to the older name.

X-Code’s debugger is just quirky. The ‘Step to next line’ function – pretty much the bread and butter function that a programmer relies on to walk through and debug code, doesn’t work. It drops into assembler code constantly, for no discernible reason. The debugger is slow, and has lots of other problems that I won’t detail here.

2) Cocoa

When Apple rolled out OS-X, they pushed developers to use a new API, Cocoa, in conjunction with a new language, Objective-C, that doesn’t really look very much like regular old C/C++ that programmers have been using for the last 20 years. Now when you’re Microsoft, with a 97% market share, you can introduce a new language (C#), that only works on your platform. But Apple, with a 3% market share, wasn’t too successful in convincing developers to write code in Objective C/Cocoa that couldn’t be ported to the other 97% of the market. So most developers on the Mac use the other API, Carbon. Now, choices in and of themselves aren’t bad – don’t like Cocoa, use Carbon, right? But Cocoa/Objective C is Apple’s baby. Most Mac example code is written in Objective C/Cocoa, and it eats up a lot of Apple’s rather limited development effort, making it harder for the rest of us developers to find help and information for the Carbon API that we actually use.

3) Hot Keys

When a programmer spends 10 hours a day for 15 years typing in text editors, he learns the keyboard macros rather well. Unfortunately, all those macros (CTRL-INSERT, SHIFT-INSERT, CTRL-PAGE DOWN, etc), don’t work on the Mac. Almost all keyboard macros are different. There is a way to change certain macros on the Mac, but not all apps obey it, and it doesn’t work very well. It would be helpful if, say X-Code offered an easy way to switch all key bindings to the default for Microsoft Visual Studio (where 90% of ‘switcher’ coders are coming from). Needless to say, X-Code has no such option.

Overall, my coding productivity is probably 40% lower on the Mac than on the PC, between X-Code’s clumsiness and my inability to use the macros that are hard-wired into my brain. This week, as I was working on the Mac port in X-Code, whenever I had a significant amount of code to write, I would save the file, switch to my Windows machine, do my coding there, save and switch back to test it. Ugh…

4) Apple’s high prices not only hurt user’s wallets, they also hurt Apple’s products.

Yes, I know X-Code is free, which is nice for the developer base that constitutes 1% of Mac users. But Apple likes to ding the other 99% of its user base in all kinds of ways, notably with very expensive OS upgrades. While Windows XP hasn’t seen a major, non-security patch update since its release in 2001, Apple has spit out a steady stream of major updates to Mac OS-X in that time (latest version is 10.4 – so 4 major updates since its 2001 release). That’s good. BUT…. for all updates since 10.2, Apple has charged consumers $129 – pretty steep for an upgrade. As a result, developers have to make the assumption that many Apple users are running old versions of the OS – as old as 10.1 if they’ve been reluctant to lay out $129 apiece for OS upgrades. And therefore, developers must write their code to the least common denominator – Mac OS-X 10.1, thereby reducing support many of the new features Apple has added since (widgets, internet-enabled .DMG files, and all kinds of other cool gizmos recently added to OS-X). That’s a shame, because, for free updates, Mac’s system works really well – better than Windows.

Other great services like .MAC are underutilized because Apple overcharges for them.

5) Limited Developer Support

OK, so you already know that only about 10-30% of the software that is available on Windows is also available on Mac. But it gets worse – most of that ported software doesn’t work as well on the Mac.

My game needed a music library to play a special kind of music file. There are two main alternatives on Windows. Only one of these had been ported to Mac. So I used it, but found that some of my music files that played fine on the PC crashed on the Mac. Fortunately, the vendor was reasonably responsive, and in about a week I got a new build of the Mac libraries that worked. Still, it was irritating and could have been far worse had the vendor been unresponsive.

Even for my game, the issue exists. Yes, I’ve ported to Mac and tried to be fairly meticulous. But there are a few small details that work better on the PC, mainly because it wasn’t worth it to support them on the Mac. The PC version remembers where the window was positioned the last time you played the game. The Mac version could do this, if I could locate the appropriate API calls, but finding that help info is hard and time consuming, especially given the Carbon/Cocoa split mentioned above. For this, and a small number of other minor features, I just decided to skip them on the Mac. The Mac version still runs great, but there are a few polish details that I skipped on the Mac. When you know that one platform will generate >90% of your sales, that platform gets the most attention, at the expense of the minor platform.

6) Ending on a Positive Note

OK – one good thing. I’ve been sending out builds of my game to beta testers, and recently sent out a Mac version, too. I’d been getting a few reports of random crashes on the Windows version, which are really hard to track down. One of my Mac testers also had a crash, but he was able to send a full debug report that either the Mac itself or X-Code somehow generates, with a full stack trace down to the function that the game was in when it crashed. Getting this kind of debug data dump on Windows in MSVC is much harder. You have to roll your own at a non-trivial cost in blood, sweat, toil and tears.

—
Anyways, Mac OS-X is not the paradigm of perfect integration and ease-of-use that it’s been touted as. As a Windows developer who could switch if the Mac really impressed me, I was instead somewhat disappointed. That said, for, say, your typical high school or college kid, there’s a lot to like about the Macs – the solid free iLife suite, the cool aesthetics, the Unix underpinnings. I think I’ve learned from the experience of developing on and using the Mac, even if I haven’t been converted to a full-time switcher.

5 Responses to “Developing on the Mac - A Windows Developer’s Perspective”

  1. Jason Maskell Says:

    I gotta tell ya Phil, you’re not giving XCode a fair shake. I’m in the same boat as you, been programming in Windows since 3.1 (not even WfW!) and before that, the AmigaOS.

    I grabbed an iBook a year or two ago now, and ditched my PC laptop, as I was travelling. The switch to XCode from VC++ 6.0 was a bit jarring, I’ll admit. But aside from debugging (which is the Gnu debugger, btw.) it’s easily up to par with VS.Net (which I am now using on my new windows projects.)

    As for ObjectiveC/Cocoa - Carbon is unsupported legacy CRAP. Don’t use it. Don’t expect them to give you example code to use it. Carbon was the cruft left over from OS9. Cocoa/ObjC is the stuff that NextStep (which is what OS X is) used, and it’s incredibly elegant. I only WISH I could use this language and foundation on something other than my tools (which are all developed in XCode using ObjectiveC and Cocoa.)

    Now, VS.Net is great these days. Especially with some 3rd party stuff like Visual Assist, but XCode is damn good too. I’m not sure where you had the name changing problem, there’s really not enough info there to understand what your gripe is, but most of the rest is just pretty unfair newbie user stuff.

    Window positioning and remember? Built into Coca. The only thing you have to do is name the window in Interface builder and it remembers the name and location automagically, as well as sizing.

    Hot keys - XCode uses unix standard hot keys like ctrl-a, ctrl-k, etc.. I admit it’s jarring going back and forth from VS.Net to XCode, as there’s no attempt on apples part to make it easy for you.

    It’s not perfect, admittedly, but it’s damn good.

  2. Phil Steinmeyer Says:

    Re: Carbon/Cocoa - the problem is that many programmers like myself, don’t particularly want to switch paradigms to Objective C/Cocoa, primarily because it pretty much eliminates cross-platform ability, sticking you on the platform with 3% market share. Nice for tools maybe, but I don’t want to learn a whole new language/API just for tools.

  3. Tim Hawkins Says:

    I am also a switcher, having wriiten windows apps in C/C++ since win3.0, and I would not touch cocoa with a barge pole. I have two options with cocoa, objective-c that I cant bind any of the C++ libs I use and can obatin everywhere, or Java, where I have to sacrifice performance.

  4. Andrew Says:

    Umm…you can freely intermix C, C++, and Objective-C code in the same file now and call among the three. So you certainly can bind your C++ libraries to your Objective-C UI layer.

  5. Peter Centgraf Says:

    I think you would be surprised at the OS upgrade rate of Mac users. I think you would be even more surprised at how little it matters when you leave non-upgraders in the dust. Follow this simple logic, borrowed from Omni Group and Delicious Monster founder Wil Shipley (http://www.wilshipley.com/blog/):

    1. You make a product to sell and make money.
    2. Iff a person is willing to pay money for quality X (e.g. games), they will also be willing to pay money for quality OS upgrades.
    3. Apple makes quality OS upgrades.
    4. People who are willing to pay for your game will also be willing to pay for Apple’s OS upgrades.
    QED

    Wil himself usually states the corollary: People who are too cheap to pay for OS upgrades are also too cheap to pay for your X (e.g. game).

New comments are disabled.