In Mac OS X 10.6 and earlier, FileVault was a feature that only affected your home directory. In OS X Lion, it applies encryption at a very low-level, encrypting an entire volume of your disk at a time, and keeping it encrypted as you use it.

I was able to enable FileVault for my boot volume with relative ease, using the Security & Privacy preference pane in System Preferences. However, the UI for this is pretty limited, and notably, it only allows you to protect the computer’s startup disk.

The way I have my Mac configured, most of my sensitive data is not on the startup volume, but is instead on a second partition called “Data” where I keep my home directory, media files, etc.  Apple’s Disk Utility allows you to erase and reformat a volume as encrypted from scratch, but what if you want to migrate a volume in-place, the way the system does the boot volume? You’re not completely out of luck.

OS X Lion ships with a low-level technology called “core storage,” which is used to facilitate a wide variety of disk-maintenance functionality, including whole-disk encryption. To get a quick look at what core storage supports, type “diskutil cs” at the Terminal command line. For a more in-depth look, type “man diskutil” and search for the core storage command documentation.

Important: This is the part of the blog article where I warn you to be very careful before proceeding. The diskutil command is capable of doing incredibly destructive things to your disk and to your data, so you should feel confident before doing anything that you have a 100% reliable backup of your data.

To convert an arbitrary volume to Lion’s whole-disk encryption, you use diskutil’s core storage “convert” command, and provide a passphrase. For example, if you have a volume called “Data” attached to your Mac, you would run something like this from the command line:

% diskutil cs convert /Volumes/Data -passphrase [yourPasswordHere]

What this does is kicks off a conversion process similar to what the System Preferences panel does when allowing you to convert your main startup volume to core storage with encryption. At any time during the conversion, you can use the diskutil command again to see status of your volumes, whether they are encrypted, not encrypted, or in-progress while converting.

% diskutil cs list

You’ll see a bunch of information, but search carefully for the named volume (e.g. “Data”) that you just started the conversion process on. You’ll find a line starting with something like:

Size (Converted):

This shows you what the progress in the conversion is. From time to time, check this manually, to see how far along things have progressed.

Caveats

In addition to the major admonition above to backup your data carefully, you should also know that after you have converted a volume, it seems to be in a sort of provisionally encrypted state where it’s still being treated by the running OS as a “native volume” although it’s been converted and is ready to be treated as a “core storage” volume. I have to confess I don’t really understand it 100%, but it seemed like a really good idea to me to restart as soon as possible after the conversion is complete.

But before you restart, bear in mind that there appears to be a bug in the login process that will prevent a user whose home directory is on an encrypted (“locked”) secondary volume from being able to log in. It seems that whatever logic Apple applies to unlock volumes at login time is not applied early enough to allow the actual login to occur. This means that if you converted your secondary volume like I did, and it contains your home directory, you won’t be able to login.

For this reason, make sure that you have a valid account to log in to whose home directory is located on the main startup volume. In my experience, the process of logging in to this main-volume account will prompt the system to ask for the secondary volume’s password in order to unlock it. Once the secondary volume is unlocked, you can log out and log back in to your regular account, with the home directory on the secondary volume.

This bug is pretty annoying. Hopefully this is something that Apple will get fixed soon, and it may be for bugs like this that they haven’t enabled full-disk encryption as a full-fledged user-facing feature of the operating system. In the mean time, if encrypting your data is important to you, I hope these instructions and caveats will serve you well.

Update: Not surprisingly, this topic is covered in some detail in John Siracusa’s Lion review.

One particularly vexing issue is the question of whether an app that is already on your Mac is “installed” or not in the eyes of the App Store application. Dan Moren of Macworld presents a great summary of the situation.

In a nutshell: if App Store thinks an app is installed, it’s impossible to buy it. If App Store thinks an app is installed, but it’s not really from the App Store, there’s a risk of repurchasing something that you already own a license for.

What this brings into focus is the very problematic nature of that small multi-purpose button the App Store, that allows for either buying an app you don’t own, or for linking to an app that you do own:

As it happens, the App Store user interface is implemented primarily in HTML. Using a surprisingly under-appreciated feature of WebKit, the omnipresent web inspector, I was able to look behind the scenes at some of the interesting HTML that supports this Buy/Installed button. For Black Ink’s button above, this is what I see:

<button version-string="1.2.3" is-rental="0" is-pre-order="0" 
   buy-params="productType=C&amp;price=24990&amp;
                 salableAdamId=402376365&amp;pricingParameters=STDQ"
   preflight="http://a1757.phobos.apple.com/us/r1000/
                 057/Purple/e7/fb/12/mzm.gytejomu.pfpkg" 
   is-install-button="0"
   large-icon="http://a1.phobos.apple.com/us/r1000/013/
                 Purple/74/8c/bb/mzi.wpgwhzjm.170x170-75.png" 
   is-update="0" item-name="Black Ink" adam-id="402376365" 
   is-free-download="0" bundle-id="com.red-sweater.blackink.macappstore"
   metrics-leaf="1" metrics-loc="Buy" title="Buy, Black Ink: $24.99"
   disabled="" its-bound="iTSBuyButton">
   <span class="price"></span>
   <span class="action">Installed</span>
</button>

Formatting XML, even with a cool app like MarsEdit, is still a huge pain. I’ve tried to make it readable here so you can enjoy some of the interesting tidbits in this markup. There are some tantalizing attributes like is-update and is-free-download, which might lead some of us to imagine whether a paid update may be a configuration away. There’s some hocus-pocus sale parameters which surely mean something to iTunes on the other end of the network connection, and there’s a link to the application’s pretty icon.

Wondering about that global web inspector trick? Any application that has the NSUserDefaults key WebKitDeveloperExtras defined to YES receives access to the sexy WebKit web inspector that is so awesomely utilized in Safari. You can define this for the App Store app by running this from the command line in a Terminal window: defaults write com.apple.appstore WebKitDeveloperExtras -bool true Make sure you quit App Store before you run it, then relaunch it.

But What’s Really Interesting…

All of this is fun to poke around at, but what I find fascinating is the preflight attribute, which points to a mysterious asset on the web. This “.pfpkg” file, which as it turns out is simply xar archive format, contains an interesting file called Distribution, an XML-formatted file that contains rules and attributes for how the application should be installed, how the App Store should locate an “Installed” app on the user’s Mac, etc. I’m not going to the trouble of color formatting this one, but have a look in a separate window:

View Black Ink’s Preflight Rules

I believe the format for this XML document is either completely or partially tied up in the way the Mac OS X Installer packages work. I have been lucky enough in my lifetime not to have to do all that much with installer packages, so I am not sure exactly how to parse the whole file. It’s clear however, that the file contains information about the application, its version and bundle identifier. It also contains similar information for each of the frameworks that ships with the application.

But the interesting stuff begins below that, where we see flags such as customize=no, and an alluring volume-check, which seems to be terminology from Installer-land that alludes to installers being able to determine whether the targeted volume is suitable for installation.

As you can see, the Black Ink preflight document is pretty boring. No, there is no customize flag. No, there are no interesting volume-check attributes, aside from the fact that this requires 10.6.6, like every other dang app on the Mac App Store. Yawn.

I decided to take a look at another application in the App Store. One that, if anything was going to be interesting, surely this one would be.

One of the things I keep reminding myself, when trying to deduce what Apple’s plans are for a variety of “would be nice” features in the App Store, such as upgrades, trials, etc., is “how does the current setup inconvenience Apple itself?” Many of Apple’s apps are shipped for free with the system and are updated for free along with OS updates. But others are not: iLife and iWork are sold in a bundle with no upgrade pricing, and other apps such as Final Cut Pro and Logic have complicated pricing, which perhaps explains why they aren’t on the App Store at all. But Aperture falls right in the middle: fairly straight-forward pricing, but it’s expensive enough that they offer reasonable upgrade charges for users who already own a license. Maybe there will be something interesting in these preflight rules:

View Aperture’s Preflight Rules

The file length alone indicates that something slightly more complicated is going on, and my eyes are drawn immediately to the JavaScript code in the middle of the document, and a function named shouldAllowPurchaseAndInstall(). Hmm, you mean there’s a choice? Usually what happens when you click “Buy” in the App Store, is you are prompted to login if necessary, and then you are warned that this is going to cost you money, it’s a big deal, etc. But as far as I can tell, a side-effect of clicking Buy in the App Store is that the aforementioned volume-check is also run on the target system, giving App Store one last chance to bail out of the process before something unfortunate is done.

In Aperture’s case, you can see by the nicely commented script that it takes care to only allows the Buy order to go through under certain circumstances. In making this determination, it checks all of the installed copies of Aperture on the system, looking for signs of App Store purchase such as the presence of a “_MASReceipt” inside the app. It also takes care to differentiate between different versions of Aperture, failing in some cases with a specific string that is presumably passed along to the App Store user.

If you’ve managed to follow along this far, you’re probably putting two and two together and realizing that the technology exists today for applications to avoid at least one of the problems mentioned above: the inadvertent redundant purchase that may happen when a user thinks it’s safe to buy an app, because “they already have a license.”

The preflight XML document may be documented in part or in full in the context of Mac OS X Installer Packages, but as far as I know, none of this is documented in the context of the Mac App Store. I do not know if any 3rd party developer has been invited to use this technique, or if it’s something we could just put into our installer packages somehow on our own, and hope for the best.

What’s most interesting about all this is that there is clearly an infrastructure in place for allowing a wide variation of behaviors, all centering around the multi-purpose Buy/Installed button in the App Store. I would like to see the volume-check options documented and made explicitly available to developers, so that we can help prevent unwanted redundant purchases on the part of our customers. I would also be curious to know if other hooks are in place or are planned to for example allow developers whose apps do show up as installed to second-guess that assumption and encourage the App Store to provide a “Buy” option to customers.

Where we’re going, only Apple knows, but I thought the details I discovered in this nook of the App Store app offer some interesting clues. I’m also interested in sharing this because I believe that the more we understand about the App Store install process, the better we’ll be able to offer meaningful enhancement requests to Apple. “Support paid upgrades” and “Allow variable behavior depending on installed apps” are fine feature requests, but if we are able to put them into the context of what Apple already knows is possible, they may be more likely to get implemented.

If anybody else has delved into the underbelly of the App Store and has observations to share, please do so in the comments, or with a link to your own blog article on the subject.

This functionality is based largely on the great work of the iMedia project, which was spearheaded by Karelia to replicate Apple’s own ubiquitous media browsing interface, some variant of which is available in Pages, iWeb, Mail, etc.

iMedia has been around for a while, but in the past year or more it has been undergoing a significant overhaul as its primary developers gear up to release the official 2.0 milestone. I have been involved in the 2.0 project for a long time now as an “early adopter,” using MarsEdit as a testing ground during the beta phase, and taking (mostly!) only the refined and polished aspects of the product for the final MarsEdit 3.0 release.

We are still ironing out some of the kinks, especially in parts of the project that were not tested in MarsEdit. One of the cool new features is support for the Flickr photo-sharing service. Like MarsEdit’s own Flickr-browser, it shows thumbnails of images on Flickr, and lets you treat them more-or-less like ordinary image files that you’d find on your computer.

Things get a little bit complicated when a user selects and drags one of these Flickr image thumbnails to another app, such as the Finder, or Photoshop. Since the image lives in the internet, and not on the local hard disk, it is not something that can be popped over to the application in an instant. Instead, a progress dialog comes up while the image is downloaded to the disk, and then the local copy is passed to the receiving application.

I try to contribute back when possible in the form of bug fixes and architectural feedback. Some of the work I did for iMedia 2.0 involved updating its drag-and-drop functionality to take advantage of new features in Mac OS X 10.6. In the process, I became a sort of de facto expert on handling dragging, which is a shame, because we could sure use a real expert, instead!

The other day, an issue came up that relates to the dragging of Flickr files. If the download is taking a while, and the user tries to cancel, mouse clicks are apparently ignored and they are stuck with the progress dialog above. I agreed to look into the issue, but there was just one problem: my network is too fast! Whenever I try to drag a Flickr image to another app, it’s done within a couple seconds, and I don’t have time to play around with clicking the cancel button.

If only I could get a really slow connection to Flickr, then I could easily test this. In the old days of Mac OS 9 or earlier, I may have resorted to plugging in a slow modem to simulate the experience of the less bandwidth-fortunate. In Mac OS X however, I can take advantage of the advanced firewall software that comes bundled with the operating system, and which allows me to configure “traffic shaping” policies on the traffic coming in and out of my computer. I found a great hint from Macworld that got me on the right track.

My goal is to cause Flickr downloads to be artificially slow. In order to achieve this goal I need to find the specific web address that the downloads come from. To do this, I use the standard tcpdump terminal utility, which also comes bundled with Mac OS X:

sudo tcpdump -Atqp -s 0 -ien1

The only part you may want to change is the bit at the end that says “en1″. Depending on the network interface you’re using, you might want en0 or en2 instead. With this running in the terminal, I go back to iMedia and start downloading Flickr files. This lets me see what the addresses of those files look like, and I discover the pertinent host name is “farm5.static.flickr.com”. Using the information I gleaned from the Macworld article, I set up the following firewall traffic shaping rules:

sudo ipfw pipe 1 config bw 15KByte/s
sudo ipfw add 1 pipe 1 src-port 80 src-ip farm5.static.flickr.com

Translation?

1. Create a pipe (you might prefer to call it a “tube”). A pipe is an artificial pass-through which can be configured to slow down, block, or otherwise alter the network traffic that goes through it.
2. Configure the pipe to limit bandwidth to a crawling 15KByte/s.
3. Configure all traffic coming from port 80 (the standard HTTP port), and originating from a specific hostname at Flickr, to pass through that pipe.

As soon as these commands are executed, the pipe is in place, and Flickr download speeds are brought to screeching halt. I can now debug the issue with the download dialog and the cancel button patiently and curiously, instead of racing to try clicking the button while I still have the chance.

When I’m done debugging, I definitely want to delete the pipe, so that download speeds go back to normal:

sudo ipfw delete 1

Mucking around with the built-in firewall on Mac OS X is not for the extremely faint-of-heart. This is why all the commands listed in this entry require “sudo” superuser privileges. Yes, you could seriously screw up your computer’s network connection if you do something wrong. But if you are the type of person whose work requires you to test and debug network related tasks, this traffic shaping functionality can be a real asset when it comes to mimicking the network environments of other people.

Addendum: I should have known I might be doing it the hard way, as usual. Clint Ecker reported on Twitter, and several folks in the comments below, that speedlimit, a Mac OS X preference pane, gets the job done in a much friendlier manner.

This resource helps to bridge the gap between Apple’s customers, who are looking for solutions, and 3rd party developers who are looking to provide them. I, along with most other developers, am grateful for this service.

A few weeks ago, Apple ruffled feathers in the developer community by quietly removing the link to the Downloads section from its formerly high-profile location in the main navigation bar on its home page. This disappointed many of us, as it will likely lead to far fewer casual visitors to the Downloads section, and consequently, far fewer click-throughs to our product pages.

Recently, The Unofficial Apple Weblog observed that Apple has stopped updating the Mac downloads directory entirely. For those few apps that happened to be among the last admitted into the directory, this is a boon. They are permanently fixed as the “most recent” updates, since March 26. For the rest of us, this does not bode well.

Does Apple plan to introduce a new App Store for “authorized” Mac apps? Are they simply disinterested in the Mac since the iPod, iPhone, and iPad have taken one such an important role in their public relations? These are some of the questions that run through the minds of Mac developers as we try to interpret meaning from the unexplained actions.

Mac developers may be feeling a bit sensitive lately. As Apple rides the success of the iPod, iPhone and iPad, those of us who are still cranking out Mac software wonder whether Apple is as excited to boost us as we are to boost them.

But Apple is riding the success of the Mac, too. The Mac is still the heart of everything that Apple does. Imagine an expansive desert where no life seems possible. A settler discovers a spring, churning out water, in the middle of this wasteland. Soon others join in, and a town emerges. Eventually a government is formed, businesses are born, and a thriving economy springs to life. When the brilliant new Town Hall is erected, everybody agrees it is the crowning achievement for the town. It represents every forward-thinking inclination the citizens of this place have, and yet it would not be possible without that water. Without that gushing spring, the town is dead. The Town Hall is worthless.

The Mac is that spring of water that allows life to thrive in Apple’s ecosystem.

I think the failure to update entries on Apple’s Mac downloads site is a consequence of staff at Apple being stretched thin. I would not be surprised at all to learn that the very people who are responsible for reviewing submissions to the Mac downloads directory also serve as reviewers for the iPhone and iPad, either full time or on-demand as submissions for the touch platforms surge.

There have been times in Apple’s history when one of its technologies was clearly being ousted in favor of a successor. The Mac (eventually) obsoleted the Apple II. Mac OS X obsoleted Mac OS 9. In the absence of a clear successor, Mac OS X running on Apple’s sexy, modern hardware, is impossible to declare obsolete. We’ll be using Macs for a long time, and loving the way they empower us to make the most of our iPads, iPhones, and iPods.

And if Apple’s earnings announcement from earlier today is any indication, based on the huge Mac sales this past quarter, they are probably still just as excited to build Macs as we are to use them.

“Every time I press cmd-N to create a new document and start typing, instead of accepting the text, it just beeps at me.”

This seems impossible to me. Creating a new document and typing into it is fundamental to my product. Surely if it was broken I would know from my own daily testing of the application. I try diligently to reproduce it, but of course, I can’t. Create a new document. Start typing. Everything works, everybody’s happy. Except the person who reported the bug.

At some point in my tinkering I stumble upon the bug. Beep. I can’t type. There it is! What a drag. This application sucks!

Now that I’ve seen and heard the bug with my own eyes, I’m more committed than ever to fixing it. But how on earth did I do it? I try several more times and am unable to reproduce the problem.

I have only spotted the issue once in my dozens of trials, yet the customer claims it affects him every single time. What explains this? Maybe it simply doesn’t happen as often on my Mac as it does on his. My thoughts turn to the brute force of AppleScript. If this happens only once in a blue moon on my Mac, surely I can reproduce it by running a script that iterates the test conditions hundreds or thousands of times. I open AppleScript Editor and enter the following:

tell application "System Events"
	repeat 100 times
		keystroke "n" using command down
		keystroke "Testing typing"
	end repeat
end tell

Nothing! Even after running it 1000 times, nothing. How can this be? How could something so common for the customer, something that I saw myself once, be so difficult to reproduce on my Mac?

After playing around a bit more, I started to reproduce it more readily. What was happening? I couldn’t figure it out, but something “felt” a little different when I reproduced it. I thought carefully about the parameters of the bug, as exemplified (I thought) by my script:

1. The command key is pressed.
2. The N key is pressed.
3. The N key is released.
4. The command key is released.
5. Typing into the new document is attempted.

I looked again at the script. Perhaps this “keystroke” command is not literal enough. For all I know it’s circumventing the normal key events that get generated when you type on the keyboard. On a lark, I modified the script to be more explicit:

tell application "System Events"
	repeat 100 times
		key down {command}
		key down  "n"
		key up "n"
		key up {command}
		key down "x"
		key up "x"
	end repeat
end tell

Here we have a more literal match with my analysis of what happens. Hold down the command key, press the N key, release, then type something. In this case I just type an x character because I figure any typing is enough to trigger the bug.

I ran this 100 times as well and no luck. The bug is simply not reproducible through scripting. I guess I’ll have to figure out what conditions are making it more likely for the customer to run into the bug. Maybe he has some 3rd party software that is interfering. Or … wait a minute.

tell application "System Events"
	repeat 100 times
		key down {command}
		key down  "n"
		key up {command}
		key up "n"
		key down "x"
		key up "x"
	end repeat
end tell

I ran the modified script and the bug immediately exhibited itself. So what changed? Look carefully and you’ll see that my previous script assumed that when a keyboard shortcut is pressed, there is a sort of nested symmetry to the order of pressing and releasing the keys. When I press keyboard shortcuts, I hold the modifier keys down throughout the stroke, and release only after the letter key has been released. But this customer has muscle memory that inclines him to instead release the keys in the order they were pressed. When he releases the N key, the command key has “long” since been released.

This subtle difference turns out to trigger a bug in my event monitoring code that, to make a long story short, robs first responder status from the default view in the document. So when he creates a new document, there is no first responder, and his typing just causes a bunch of beeps. When I create a new document, there’s always a first responder, so I don’t see the bug.

As difficult as this bug was to track down, it would have been near impossible without the theory testing, disproving, and ultimately proving tool of using AppleScript and System Events to zero on in the behavior. Sometimes when the steps a customer provides to reproduce a bug seem exactly the same as what you’re doing, you’re just not trying hard enough to find the difference.

The future of software is on the web. That’s what they keep telling me. I just smile, and say “I don’t think so. There will always be compelling technologies on the desktop.” I believe this, but I admit it carries an odor of blind loyalty to my comfort zone.

People who argue the other side have latched on to a few admittedly stunning aspects of the web, and they seem to believe that these charming characteristics alone ensure a course for long-term victory over all others. These attributes include:

• Cross-platform. You can run a web app on any computer that has a capable browser.
• Ubiquity. You don’t need to be near your computer to run a web app. You just “log in.”
• Instant updates. No need to coerce customers to update, just change the code on the server and they’re quietly updated to the latest running code.
• Open, standard technologies. You have control over and  access to most of the source code at the heart of your application.

Attractive indeed. If you imagine a world where the sum of all things you can do with a computer is exactly matched, and locked down for all time with what you can inside a browser, then the arguments for the web are persuasive. Why write for a specific platform when you can write for all platforms at once and gain the other advantages as well?

The error is in disregarding the many unmatchable attractions of “the desktop.” When I say desktop, I mean any platform that provides applications with more features than the standard web. iPhones are “the desktop.” As are Android, Palm Pre, Macs, PCs, and Linux. All offer features and functionality above and beyond what you can do on the web itself.

But the web can do a lot!, you cry, and point me to examples of ingenuity such as 280 Slides, the flagship proof-of-concept from 280 North’s impressive library for implementing web apps in a way that is reminiscent of programming in Objective-C. What these people are doing is mind-blowingly impressive, and if I decided to write a web app for some reason, I would probably use technologies like these.

But if I want to write a truly great app, it has to be a desktop app. And this will be true forever, or until there is no difference between the web and the desktop. I grant you, if the web becomes the desktop, something I find very unlikely, then the web will have in fact won by default.

Anything You Can Do…

Companies like 280 North are investing years of engineering time into a necessary pre-requisite for web-app domination: bringing the web’s capabilities up to approximately what the desktop offers. I quipped on Core Intuition that “Web 2009 = Windows 95″. It’s a play on an old bumper-sticker from Apple, that poked fun at Windows for finally having “caught up” to Macintosh’s 1989 feature set, in 1995. The amount of work done over the past few years on web app technologies is staggering, but when you take a step back, they celebrate victories over things we have taken for granted for years on the desktop. Things like drag and drop and animation are at least possible on the web. Other niceties such as inter-application scriptability would require a total overhaul of how web browsers behave.

The problem with the game of catch-up, is you only ever win if your target is moving slower than you are, or better yet if they stop completely. All desktop platforms are innovating to offer developers greater and greater capabilities that peer into the future of what your high-powered CPUs, GPUs, and peripheral hardware makes possible. Meanwhile, most web platforms are just trying to catch up.

And catching up is hard for many reasons, not least of which that they have no idea where the desktop is going. None of us do, and Apple’s announcement yesterday of the iPad is a great example of this. The goal of a “vaguely Mac/PC-like application interaction environment on the web” is thrown a curveball when desktop vendors such as Apple are constantly picking up the goal, brushing it off, and setting down again on a completely different path you’ll have to now forge a trail to.

It’s an unfair fight. We know exactly what the web can do, and we have a good idea of what it plans to do, thanks to its (laudable) open standards. But none of us has any idea what the next iPad, iPhone, Wii, Xbox, TomTom, whatever, will do. Don’t get me wrong: the web is excellent at innovating, but it innovates primarily for publishing and social interaction. It doesn’t innovate on desktop UI or device integration, the very areas where brilliant desktop applications shine. And it does innovate, as I have already suggested, in the art of catching up.

Anything you can run in a web browser can also run inside a desktop app, thanks to the modular embedding capabilities of WebKit on the Mac and Internet Explorer on the PC. However, it should be obvious that the inverse is not true. When something truly innovating and mind-blowing happens on the web, I can drop it into a WebView on my Mac and make it a part of my desktop experience. When something mind-blowing happens on the desktop, you can bet you’ll have people scurrying to painstakingly imitate it on the web. It takes a lot of work, and a lot of time, and sometimes it’s not precisely even possible. But eventually they will come up with something reasonably close.

I imagine in 5 or 10 years the web will have caught up to something resembling how desktops behave today. But I can’t even begin to imagine what we’ll have at our fingertips on the desktop, by then. iPad? We ain’t seen nothing yet.

1. If you’re the slightest bit curious, buy Mark Dalrymple and Scott Knaster’s affordable book, Learn Objective-C on the Macintosh. It’s great that this book not only starts from the very beginning, but is available as an easy electronic download, for instant gratification.
2. If you’re convinced you’re in for the long haul, but prefer to learn at your own pace and in your spare time, pick up Aaron Hillegass’s Cocoa Programming for Mac OS X.
3. If it’s time to put the pedal to the metal, and you want to minimize the chances of failing as you learn the basics of this art, drop everything and enroll in the Objective-C and Cocoa Bootcamp class at Big Nerd Ranch.

Big Nerd Ranch is run by the very Aaron Hillegass who authored the book you picked up in step 2, and he teaches the Cocoa bootcamp class himself. The class is not cheap, but neither is it exploitatively expensive. You will learn to program for the Macintosh with a group of classmates, living and programming on a bucolic country retreat, where your meals and lodging are taken care of.

The Big Nerd Ranch concept is exciting, and I have often fantasized about attending a class there myself. I’m probably overqualified for the boot camp, though as with most life experiences, you learn something when you review the basics. The ranch offers a variety of classes in addition to the boot camp, including courses on more advanced Cocoa programming, iPhone development, and even on Django and Ruby on Rails web programming.

Right now, Aaron is busy building a bigger, better, greener, serener (funner? funnest?) Big Nerd Ranch. He’s actually bought a large plot of land and is drafting plans for several new buildings. He’s treating all of us to many glorious details on his personal blog: possible/probable. The blog frames itself as the chronicle of a man in his mid-youth, aiming to improve an already successful life by taking chances and aiming for the stars. It so happens that his stars form a constellation that idealizes and glorifies learning to program on the Mac.

When you check out the blog, be sure to read through the archives. You’ll be riveted by his stories of searching for suitable property, securing bank loans, winning and losing architects, and grappling with the underlying question of just how crazy pursing this dream might be.

Fortunately for us, Aaron seems to be guiding his own life with the words of his blog title, “possible” and “probable.” I interpret these slash/stroke separated terms optimistically, as I expect he does. If you can imagine something, if it seems vaguely possible, then with a little work it is made probable.

I find Aaron’s optimism inspiring, and his stories remind me of my own possible/probable dreams still waiting to be fulfilled. His zeal for the pursuit of happiness rests safely between recklessness and painful deliberation. He recognizes that while frightening risks need to be taken, putting in hours of hard and tedious work will greatly improve the odds of success.

We should all get to work turning our own possibilities into probabilities, because nobody else is going to do it for us. With the help of Aaron’s blog, we might find ourselves inching just a little bit closer.

If you love your Wii and your Mac, then this app is probably worth taking a look at. Congratulations, Manton, for finally shipping :)

We’re proud to announce the immediate availability of episode 3, where we talk about WWDC, MobileMe, iPhone 3G, and a bunch of relatively unrelated stuff.

Check us out!

In this episode we talk a bit about travel and how we keep up on our indie business commitments on the road. We also chat about the recently updated book from Aaron Hillegass: Cocoa Programming for Mac OS X. Manton bought a copy but I apparently think I’m too good for programming books.

Finally we touch on the question of distributed source control systems, such as git, mercurial, and bazaar, and whether we should be switching to them or sticking with trusty Subversion.

Enjoy!