Say what?

OK. .mac is Apple’s much touted, and honestly, underdeveloped mail hosting service/sync service/online disk space/remote access service that was recently rebranded as mobileme/.me. Frankly, it’s a bastard stepchild. While I’ve had legitimate uses for it and it’s premium pricing (just wait, I’ll explain), most users have never needed most of what it offers, or could easily get it for free. The biggest thing going for it lately was .mac-based syncing for the iPhone, that offered a compelling reason to shell out the bucks.

Well, Google is now offering exchange-server based syncing called Mobile Sync that works with a number of smart phones – including the iPhone. With it, you can keep your gmail-based contacts and Google calendars wirelessly synchronized with your iPhone. And it’s free.

OK. It’s hardly the end of the world. There are still a number of advantages that .mac has, but Google sync just made it a lot less compelling.

Pro’s for Google Mobile Sync:

• Easy to share calendars with other people and fairly easy to see other people’s shared calendars as long as they’re on Google. Google calendars has it all over iCal here.
• Reliable. You don’t have to deal with the vagaries of Apple’s built-in syncing services. Google has the server, Google keeps the calendar. Any changes you make to it after using the calDav tools like Calaboration to give you direct access to your Google calendar in iCal will be reflected within minutes no matter where else you look at your calendar. The calendar and contacts are synchronized over the relatively tried and tested (yes, I’m grinding my teeth saying it, but credit where due) Exchange activesync services. Since the current Apple Address Book app in Leopard natively syncs to any specified Google Mail account, this gives you a completely different channel to keep your mail and contacts and calendars synchronized on your phone and desktop. It also makes them available via the web, while letting you use the interface (web or local) that best suits your way of working.

Cons:

• Privacy. Well – there are some who worry about Google and privacy. I understand these concerns, but don’t worry enough to not use them where they’re the best tool for the job.
• Five Calendars synchronized. You can have more than five calendars, but only five of them can be synchronized to your smartphone. I solved this by grouping what used to be separate calendars together.
• Ease of setup. If you have a new computer and iPhone – great. No problem. However, if, like me, you have a bunch of contact and calendar information already, then .mac is still the clear winner here. Between consolidating calendars, backing up data on the phone and the computers, exporting out individual calendars to import into Google cal, importing them, etc… it’s hardly a painless synchronization  or one-click export. If, on the other hand, you already use Google and never used iCal anyway, then you still have the option of viewing the calendars in iCal. This is useful because a lot of programs in OSX are aware of the address book and the iCal calendars.
• .mac plays better with mail programs than GMAIL. Especially the built in Apple Mail.app. Go figure. That said, this is true because Google does a few non-standard things to make tags work within the folder paradigm that most mail programs use.
• Doesn’t replace the “Back to My Mac” functionality. – though as I recall LogMeIn now has a free mac program that allows you to get some of that (remotely controlling your computer) for free.

So… getting all this to work can be a little harder than .mac, and you still don’t get to synch bookmarks, but it’s free, and it works. For people like me who’ve had a .mac address for years, well, we’re not giving it up. At this point though, I can’t really point to mobileme sync as a compelling reason to push .mac/.me/mobileme.

Hearing this, I revisited it and am quite impressed. For ajax-based work (like custom coding an editor) it’s more complicated than straightforward PHP/Javascript development for small sites. This is mostly because of the need to tell at least two sets of files what’s handling a request for a web page before you even get to wiring up the python code to the template. What it gives you in return though is an absolutely stunning level of scalability, as well as a very rapid method for prototyping all of your changes.

The remaining headache is the need for some form of version control. You can have different ”versions” of an app posted, and roll back to a prior version, but there’s no integrated access to a common file repository where people can independently work on different files and see the combined changes before deploying them to the server. Guess I’ll have to figure out how to set up my own repository and how to make it so my fellow developers and I can work on it, along with a workflow that won’t cause headaches in deploying to the Google apps site.