WWDC 2013 is fast approaching, and chances are good that we'll get some sort of preview and song and dance about how iCloud sync is even better than ever for developers. Honestly, would you expect Apple to say anything else?

But how are we going to know Apple has finally fixed iCloud syncing for developers and is really serious this time? And I'm not just talking about Core Data syncing, I'm also talking about the APIs developers are given to push document data back and forth. The broken stuff, the things developers laugh at Apple about and have given up on.

Here's my short and inconclusive list of things that will let us know iCloud might be ready for real world developer use.

1: iCloud APIs are no longer tied to monolithic OS updates.

This was the very first thing that set off alarms in my head when Apple introduced the iCloud APIs. It's baked into Foundation. Not "at the foundation of the OS" marketing talk, but the APIs are exposed to us via Foundation.h. This is a very, very bad code smell. Things on the web and in sync land move fast, and if we have to wait 12-18 months for something to be fixed or updated, why in the world would a developer adopt it?

Oh, you say it's all fixed on 10.9? That's great. How about all those users who aren't updating to that OS for whatever reason? Oh, they are screwed? Great. That's what I wanted to hear.

.Mac syncing sucked- but it had a downloadable SDK and it was the sane way to do things. You could download an update which fixed bugs and it was possible for Apple to add new APIs without having to do it in sync with the OS. Just because an idea had a bad implementation doesn't mean the idea is wrong.

2: iCloud sync uses sane APIs.

Dropbox is popular because it's a folder. And you put stuff in that folder. And it syncs that folder. And it just works.

Apple needs to make iCloud document syncing that simple. No need for file coordinators, no blocking when saving, no crazy continueThisBlockWhyIsTheStack40FramesDeep: methods, simple notifications when a file is updated.

There's an old AppKit/NeXT saying: "Make it work. Then make it work right. Then make it work fast."

For iCloud syncing I propose: "Make it easy. Make it simply work. Get crazy after that."

We obviously need atomic operations at the package level- but don't make it required for the developer to adopt. Or at least make it work without exposing how it's happening. I want a folder that I can write to, that'll just sync. Make it happen and make it dead simple to adopt.

3: Apple uses the iCloud APIs for their own apps.

When iCloud was introduced, Pages on iOS certainly wasn't using the same APIs Apple gave us for syncing. Why not? I guess because it was broken and/or unreliable. Something third party developers had to find out on their own.

When Apple's consumer apps use the exact same APIs we are given, it might be time to seriously look into using iCloud for doc syncing.

4: Apple gives us some server side tools to kick things.

Why are there no developer tools that let us see the status of syncing data? Why is there no website for developers to log into to watch data transfer from one machine to another, or to know which bit of data came from where? Does Apple understand how hard it is to debug things when we have no access to "The Truth"?

I think Apple's answer as to why we don't have this is because "it should just work". Well, it doesn't. And to pretend otherwise is to sow distrust among your developers. Start with an assumption that it's going to break, and break hard. Give developers tools to analyze and clean things up. Apple gives us pretty great tools for debugging and improving code running on our local machines. We need the server side equivalent of that.

…

I've got more ideas, but I think these four things would be a great start.

I really want to use iCloud. But I just don't trust it and I don't want to waste my time implementing and debugging things when there's other syncing solutions out there that just work.