I'm a little late on the draw on this one. I didn't actually listen to the episode until Sunday. However, Andy Ihnatko mentioned my iCloud presentation on MacBreak Weekly #272! I've noticed a definite traffic surge since the show. I hope everyone likes what they see, and decides to stick around. If there are any topics you'd like to see discussed, please leave a comment, and I'll see what I can do.
The MacTech conference was a lot of fun. I was the last person to take the big stage, and it looked like my presentation was well received. A lot of people came up to talk to me afterward. The presentation itself started with a brief overview of iCloud--specifically a description of iCloud Storage (the API that developers can use to sync their own apps). I describe how it works, then I talk about some of the problems.
Now, I wasn't talking about having trouble just getting it to work. The iCloud storage API is a bit complicated and can be hard to set up properly; however, that's a separate issue (and one which I've dedicated a lot of time and effort going over in my book). No, I spoke about the unintended consequences that can crop up even when everything is working as advertised.
In particular, what happens when we, as developers, release a new version of our app that changes the data format. Imagine that one of our users updates their iPhone but not their iPad. They open a file on iPhone. The new version updates the file format and saves the new version to the cloud. Next, they open it on the iPad and bad things happen. Here, "bad" can cover a wide range of possibilities; however, the scenario that worries me the most is that the old app may think it's working properly, but it actually has invalid/corrupt data. Then, it saves the now-corrupt version back to the iCloud--and the corrupt data is sent out to all the user's devices.
Notice that data migration isn't a new problem. We've been dealing with this since the invention of software. However, by adding auto-syncing, auto-saving and automatic conflict merges, iCloud cranks this up to 11.
Andy summed up the problem pretty well on MBW. It's about 52 minutes into the show. The only thing I'd like to add is that I also discussed a few possible steps we can take to mitigate the problem and control the user experience. These include:
- Add robust error checking, and especially adding data validation to make sure we're actually loading reasonably looking data.
- Change the data's UTI for the new version, creating a one-way gate. The old version won't even see the new files.
- Add metadata to our apps data that we can check before loading the data. This lets us detect new versions and post proper alerts to the users; however, it must be done proactively. We need to build the system into our original release--before we even anticipate changing our data format.
- Finally, test, test, test, test. Test what happens when the new app opens old data. Test what happens when the old app opens new data. And test what happens when you have conflicts both on the old device and on the new device.
So, it's not hopeless. But it's something we really should think about before we release our apps. If you're interested, you can purchase the video of my iCloud presentation from MacTech here. You can also download the slides, though I don't know how much use they will be without the presentation itself.
If you want more information, please drop a note in the comments. If there seems to be a lot of interest, I'll write something up.