After two months of work we recently put the finishing touches on our first ‘real’ Mac product: iPhone AutoSync.

What is it?

Out of the box, the iPhone does a great job of synchronizing with the Mac’s built in PIM applications, Address Book and iCal, and bookmarks, courtesy of Safari. After years of somewhat kludged together sync solutions on the Palm and Windows Mobile (at least on the Mac side of the fence), the iPhone feels great. One thing quickly becomes apparent, however: after editing a friend’s number in Address Book, I finished a few things, grabbed my phone, and was out the door. When I went to call him, I noticed that my recent edit was not reflected on the iPhone. As it turns out, the iPhone syncs only when it’s placed into its dock (or, manually, when you right-click on it in iTunes and select “Update”). Any changes you make between docking and undocking, however, are lost. Since my phone spends most of its time in the dock, these have to wait until the next time I come back to my computer.Enter iPhone AutoSync! iPhone AutoSync monitors your three synced applications, and, when changes are made, makes a note. After a few minutes, if no more changes have been made, it triggers a sync with your phone. Thus all your information in up to date in both places, pretty much all the time.

The Fiddly Bits

Warning: Here there be geekery. Skip past if you're not interested in the behind-the-secenes.

The main challenge when writing a faceless app is to minimize resource usage. Since iPhone AutoSync is always running, we don’t want to hog too much memory, processor time, or other system resources. However, we also want to make sure we are responsive, and the user doesn’t have to wait too long for us to kick in.Our first attempt used kqueues. Mark Dalrymple and Aaron Hillegass’s wonderful book, Advanced Mac OS X Programming has a great set of examples making use of kqueues. In a nutshell, a kqueue will allow you (among other things; they’re very powerful) to watch a directory for changes. When any application reads or modifies files at that path, your application gets notified. Pretty much just the ticket, right? As it turns out, we were using far too big a hammer here. On a tip from Dave Nanian, we grabbed Notification Watcher, and found that each time you edit an Address Book entry, or modify an iCal event, a series of global notifications gets sent. By listening for those, we were able to find out each time the user’s data is modified, in a much lighter-weight system than kqueue.iPhone AutoSync has a giant bottle-neck, however, and that’s iTunes. Since we keep close watch on our target applications, we could immediately sync the phone each time they change. However, a sync is a relatively expensive operation: we don’t want the user’s iTunes hogging CPU and changing its UI every 30 seconds as they plan out their week’s schedule. The answer here was an aggregator: each time a change event occurs, we set (or reset) a timer. Once no change events have fired for a few minutes, we assume the user has finished editing, and fire the sync. This meant that there would be a slight delay between a change and the iPhone being totally up-to-date, but after a bit of experimentation, we think we’ve found the right mixture between the two extremes.

Finally

Getting iPhone AutoSync out the door reminded me how hard the last 10% of a software release can be. This post was written using Daniel Jalkut’s brilliant new blog tool, MarsEdit 2, just released. Congrats to Daniel on a great product, and conquering that last 10%; I feel your pain (though MarsEdit is of course a much bigger production than iPhone AutoSync.)

This entry was posted on Tuesday, September 11th, 2007 at 12:59 am and is filed under iPhone, Mac. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.