I bought a Mac Mini last week. The day before I left on vacation, a tiny box from Apple appeared at my doorstep. In a fit of boldness, I decided to take it with me and spend part of my weekend in Texas pounding away at it. I wanted to get a feel for the kind of user/developer experience a Mac user would get as an “out of the box” experience and share it with you.
A few of caveats before I begin:
Big kudos goes to Apple here. My Mac Mini was a relatively high-end configuration. It had a 1.42Ghz G4 CPU, 80gb HD,512Mb RAM, DVD RW, built-in Bluetooth/802.11b/g, plus Bluetooth mouse/keyboard. Microsoft employees actually get small discount from Apple, and the total “shipped to the door” cost to me was under $1000. Looking back now, I recommend bypassing the Bluetooth mouse/keyboard combo and sticking to whatever Mouse/Keyboard combo you like (Microsoft, Logitech, etc.). Aside from my rants about the mouse (see next section), I also noticed my Apple bluetooth keyboard occasionally didn’t send a character to the screen. I can’t tell if this is because I’m having difficulty in typing with a “non-split” keyboard or if it was a Bluetooth problem.
Opening the (extremely small) box was simple, as was hooking the computer up to the monitor. Startup was very simple, and after a short “first user setup” sequence, it hooked up to the Internet and identified several updates to install. This procedure was simple, and each step was clear. Other than the mouse issue, a Windows developer would have little to no difficulty getting used to OS X (and to an old Unix guy like myself, I'm quite fond of popping up a bash shell anytime I want -- of course, I can install Windows Services for Unix and get bash on my XP box).
The overall visual and performance, even for such a tiny box like the Mac Mini, is quite impressive. The glass effects and visual behaviour of the dockbar is impressive, and overall visual presentation is simple. One really cool thing is Expose, which allows you to quickly organize and look at all the open windows at once with just one button.
In my opinion, this is a major Achille’s heel of Apple – their persistent belief that people want/need a one-button mouse. My Mac Mini came with a Bluetooth keyboard and mouse, but the experience of a one-button mouse was nothing short of miserable. What is ironic is that I suffered the EXACT same problem when I was first developing on a Mac IIfx running A/UX back in 1990. You'd think that Apple would at least offer a three-button mouse as an option (although the latest news from Engadget says Apple is about to offer a two button mouse -- That would be nice -- a 21st century OS with an early 90's mouse). Fortunately, the Microsoft wireless mice/keyboards work GREAT with the Mac. Even better, almost ALL software on the Mac is actually smart enough to understand right-clicks and the scroll wheel. Um, Apple...if you wrote the software to support 3 mouse buttons and a scroll wheel, why not offer hardware to match the functionality?
Let's be honest, you probably won't buy a Mac Mini for its gaming power. That being said, I decided to give a few games a whirl. The Marble Blast game that came with the Mac was cute (but simple). The "Nanosaur2" game bordered on stupid (both in terms of gameplay and controls). I also own World of Warcraft, which will install on either a Mac or PC, so I loaded that up and gave it a run. Not pretty. Yes, it was playable, but barely.
This was really the ultimate test. What is the experience like to develop on a Mac? How easy is it, compared to something like VB.NET or C# development? This is my summary: In spite of Apple's XCode development tools coming for free with Mac OS X, developing on a Mac sucks like an inverted hurricane.
There are two primary paths a developer can take when writing code for OS X:
1) Carbon: This is the C/C++ interface for writing Mac OS X applications
2) Cocoa: This is the Objective-C/Objective-C++ interface
Unlike the managed/unmanaged demarcation Microsoft has with .NET, the Carbon/Cocoa difference is more about preference and background more than execution environment. For instance, you can call Carbon APIs from Cocoa, and vice versa.
Performance-wise, Carbon apps are (theoretically) a little slower because they use a more object-oriented framework. As a comparison, one game programmer indicated that a file management component took 800 lines of code in Cocoa, versus 18,000 in Carbon. Generally speaking (from what I can tell), newer apps should be written in Cocoa, while older apps (C/C++ based) will benefit from using the Carbon APIs (Office for Mac is written using Carbon). I will focus on Cocoa app writing for this entry.
I wanted to start with a simple window that had a few controls, just to get a feel for what my development would look like. When you launch XCode and create a new project, you’re faced with a large array of startup options, generally either Cocoa or Carbon apps, but also including the ability to develop Java EJB or Swing applications (I'll skip over this part except to say this -- if you want to write a Java app, forget about XCode and use Eclipse).
After you select a Cocoa application, the XCode project window opens with a set of pre-populated files. Although it looks nothing like Visual Studio, I didn’t find the layout to be too arcane/overwhelming. One thing that was VERY different, however, was the process to create and wire up a GUI. To begin with, you must launch a separate Interface Builder tool. The tool is laid out rather oddly (from my prespective), but a quick read of some developer documentation helped. Unfortunately, playing “drag and drop” with the controls was the only easy part of the task. The process of wiring up outlets and actions (similar to properties and events in .NET) is nothing short of wierd. What would take a .NET developer a scant few minutes to do takes easily three to four times as long with the Interface Builder. Compounding this is the fact that generating the code is effectively a one-way trip. You really can't go back and add/change things without a lot of pain (According to the Apple docs, “Once you have created .h and .m files for a new class…, you should not use the Interface Builder Info window to add more actions and outlets to the class.”).Once the code is generated, you're back in the XCode development tool, and you begin "filling in" the code stubs generated by the Interface Builder tool. This process is also quite painful, as the XCode editor has only redimentary code sense and contextual help (again, I emphasize I'm comparing to Visual Studio). In addition, there is little to no help to warn you about potential errors in your code (I didn't turn on the "predictive compilation" feature though, so maybe that would have changed things -- XCode has some interesting features that appear to be turned off by default). Once you've managed to write your Objective-C code correctly, you go through the standard "compile and run" cycle. Debugging is also a challenge, but if you're familiar with gcc/dbg, you should be somewhat comfortable.
Apple has a nice hit here with the Mini. It's definitely lowered the bar for people wanting to bring a Mac into their lives, and it boggles me why PC manufacturers can't offer something in as small of a form factor as Apple has done. For a non-gaming Mac user experience, the Mini delivers in a nice package. For a developer experience though, the Apple developer tools have a long way to go.
Remember Me
Theme design by Jelle Druyts
Pick a theme: BlogXP calmBlue Candid Blue dasBlog Discreet Blog Blue Elegante essence Just Html Mono Movable Radio Blue Movable Radio Heat orangeCream Portal Project84 Slate Sound Waves Tricoleur
Powered by: newtelligence dasBlog 1.8.5223.2
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2009, David Weller
E-mail