Developing on the Mac – A Windows Developer’s Perspective
Thursday, September 29th, 2005Good 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.