Speculations about developing with iCloud

It's been three months since Apple revealed it's vision of the cloud to the world. After its introduction, much was written (e.g. It Just Works) about how iCloud compares 'philosophically' with others, most obviously Google. Now, supposedly close to launch and with iCloud in the hands of developers, there seems to be surprisingly little written about how that philosophy translates into developing a modern iOS app.

Apple promises consumers that things 'will just work'. Just keep using apps in the same way and they will magically remain up-to-date across all your devices - in truth I'm not sure more magic was promised. Apple might be making a similar offer to developers. In principle iCloud means that an ObjectiveC developer with XCode can create and distribute apps containing this magical ingredient without having to learn any new skills, without having to develop any cloud-based components at all. What's more, with relatively little extra work, they can support the Mac as well.

Of course, even within the Apple eco-system, this simplified development model is only true for a certain class of app, specifically those where the user is essentially creating/editing a document that can be synced via the cloud. Nevertheless that class can cover everything from task management apps (like iNote) to adding personalisation features such as 'favorites' to apps that consume third-party web services.

As always there is a cost: no support for Windows PCs, no support for Android devices, no support for the web.

Without direct knowledge of the iCloud API it's hard to be precise, but one can guess at some of its key features. For example it seems likely that an app developer can read or write a document at anytime - a considerable convenience over talking to a web service that may, or may not, be accessible. However a model that provides such a convenience must, necessarily, introduce some additional conceptual wrinkle elsewhere, for example some form of asynchronous updates. To help with some of these issues, the iCloud framework seems to make heavy use of the concept of versions. According to John Gruber, versions also lie at the heart of the solution of another tricky technical problem; that of handling conflicting updates. According to Gruber, iCloud will not advertise the notion of conflicts, rather it will determine it's version of 'truth' in the cloud and push it to all devices. Although managing conflicts may be less common in day-to-day, single user environments they do happen and surely some apps (at least) will be able to access conflicting versions in the cloud and allow a user to interactively manage the merging.

There are alternative approaches to handling conflicts - for example you can do away with the concept of versions altogether at the expense of requiring online access whenever you wish to access a document. That approach - of having a single version of the document held in the cloud, accessed on demand and being updated at the level of every key-stroke - is already available in Google Docs. The truly dynamic nature of this approach is best demonstrated when a document is being shared and edited by multiple authors simultaneously - a feature that (based on what isn't said) isn't addressed by iCloud at all. But, just as I am sure iCloud will address shared access in time, Google is in the process of adding off-line access to Google Docs. It will be interesting to see how Google address conflicting updates.

It has been repeatedly stated that iCloud is more than just storage in the cloud; for example it involves computing deltas, pushing updates and client side version handling. Intriguingly iCloud has identified a generic set of operations that can be used across a wide range of apps. As such iCloud represents an abstraction of synchronised, cloud based app storage. It is an abstraction that presents a simple API to client based app developers on the one side and hides a complex combination of cloud based services and OS components on the other. It significantly narrows the range of technologies that an app developer needs to work with. Even the idea of having apps resolve conflicts has its merits; after all an app is particularly well-placed to present domain specific content.

if iCloud provides a useful abstraction, then I wonder how long it will be before somebody else offers an alternative, more open, implementation? Maybe it wouldn't have all of the advantages of iCloud - it wouldn't be baked into the OS and I don't imagine anybody would be offering it for free - but it could offer simplified app development while not being restricted to purely Apple products. In fact one could even envisage an HTML5 based SDK making it available to web developers. Of course Apple will have already thought of that...

Social DNA

There has been a lot of discussion recently about whether Google has, in their DNA, what it takes to 'get' social.

Well I think I 'get' social but I'm not sure how much my life is improved by getting the news 30 mins ahead of everybody else and I'm pretty certain that I don't need to actually see people go through the arduous process of constructing a reply in real-time. So I'm well disposed to the idea of a 'social layer' that improves the processes I'm already familiar with - although a better analogy might be a 'social render' that can be used to fill in the gaps and smooth over the rough transitions.

A good test will be how Google contacts are handled.

Google contacts is a tremendous asset. With an Android phone, all you need to do is enter your Google credentials and your email, calendar and contacts are there. I've got an iPhone and, with slightly more configuration, you can do the same thing. The thing is that Google contacts was a the right place at the right time. Originally my contacts were in Outlook and then, via some complex synchronisation story from Plaxo, they ended up in Google. I can't see a compelling reason to move them. Sure I can think of some 'nice-to-haves' but most of the alternatives have fundamental flaws.

For example, could I use Facebook instead? On Facebook I don't have to worry about changes to my friends' contact details - I see the updates pretty much as soon as my friends make them. Very nice to have. But, at the moment Facebook, doesn't handle all those contacts who don't have a digital presence, and there are - and will remain - plenty of those.

On the other hand it would be nice if Google could, for those of us that have defined a profile (even if it was only to test out Buzz) provide some sort of live link to those of our contacts that have also defined a profile (and set suitable sharing options etc etc). Technically it wouldn't appear to be that hard, afterall it's a basic construct of something like Facebook. Clearly there must be hidden complexity because it wasn't built in at the start that relates to the number and range of services that Google offers. For example it was only recently that your profile could be properly tied to Picasa web albums.

Of course Google might have no intention of beefing up 'contacts'. Maybe they will build on top of the Buzz infrastructure and provide a new way to add contact info into the list of people you are following. But that would seem to increase the 'conceptual count' yet further.

Personally I'm looking/hoping for my contacts to become more intelligent and gain a social element and for that enhancement to carry across to my phone.

On an unrelated note, how does 'social DNA' compare with 'the selfish gene'? 

Why do I do it?

I don't blog much and I'm curious as to what, on those odd occasions, finally drives me over the edge.

It seems to be a desire to clear my head of some on-going irritation or a minor thought that just won't go away and needs to be expressed. Writing it down seems to be a way of exorcising it - just like writing a note to myself and leaving it on the kitchen table helps me sleep if I'm travelling the next day.

Of course blogging about it brings in the dubious advantage of turning the whole process into a public display. There is a possible upside - the right to wear an "I told you so" T-shirt when the rest of the world realises that you really did identify the crux of the problem and offered a simple "Why don't they just...." solution. The downsides seem rather more numerous and more likely; people are privy to the odd things that bother you and, worse still, you're not even right about them.

I write this because I feel a deep resevoir of irritations developing that will need release in the near future.

But, in an attempt at some level of objectivity, I need to look back at my January post. It was written just before the launch of the iPad.

T-shirt score to date : zero out of one. 

The iPad did not have a revolutionary approach to content input - more importantly it didn't need one. It was already significant for being a better way to consume [various types of] content. Why wasn't that enough for me?

Can they do it again?

What does it take to start blogging again? A new year? A new decade? Or the opportunity to pointlessly speculate about an as yet unannounced product?

The question that keeps coming back to me is "Can they do it again?"

Not "Can they break into a new, billion dollar market?", not "Can they redefine the way we distribute and buy apps?" but "Can they reinvent the way we interact with mobile devices?"

I remember the time before the iPhone was launched. We had an HTC running Windows Mobile in the office with a touch screen and a dinky little stylus - you could use your finger nails if you angled them just right. OK, it was a bit fiddly but it took most of the fear away when entering a long URL into the browser's address bar. But we knew there were better things coming. We had all seen those iPhone mockups - the one's with a virtual, circular scroll-wheel floating over the interface. We couldn't wait.

And then there it was ... and it had a whole new vocabulary of gestures; slides and flicks and pinches and you could type with your actual fingers and there were '.com' and '@' buttons when you needed them and the interface was simple and hidden and only came to life when you actually touched it. And before the hour was out you knew that was how it was supposed to be and when you actually got one in your hands you just smiled at how much fun it was. And the best part was nobody knew a thing.

Can they possibly do that again?

Maybe they don't have to. A tablet with the touch interface of an iPhone would be a fun way of consuming digital content - but $500-$1000 worth of fun? Surely it's got to be as good as, if not better, than the iPhone when it comes to creating content, when it comes to text entry. And the point is that if it does just what the iPhone does, it won't be better - it will be worse - because you can use both thumbs on an iPhone or you can use it one-handed and I bet you won't be able to do that with a 10" tablet.

OK, so this time they don't have to invent, and keep under wraps, a whole new way of interacting with a mobile device; all they need to do is invent a new way to allow me to write next years blog entry on a tablet. Except that inventing things is hard and rare.

Advertising on Google Local

David Galbraith has noticed Google testing out what he calls 'adballoons' on Google Local.

Searching for hotels in New York brings up a pair of blue sponsored links for two specific hotels ('W Court Hotel' and 'Courtyard Manhattan Hotel'). Clicking on these brings up the balloon on the map.

By comparison, searching for hotels in San Francisco brings up a generic sponsored link for 'San Francisco Hotels' which takes users to a new page.

Google Base doesn't like 'geotagged'

I've just tried creating an item in Google Base of a new item type Spatially Referenced Photo with:

• two details called geo lon and geo lat (I tried including the colons but it strips them out) with values of type Number
• a label of geotagged - unfortunately the label was rejected as 'misspelled'

I've asked for an exemption so here's hoping...

Update: as of Nov 21, 2005 6:42 PM Google Base does like 'geotagged', check out a Google Base item pointing to a geotagged Flickr picture of the Mill Race in Cambridge.

Tags: geotagging

Third parties indexing Google Base

So, before hard evidence comes to light, let me speculate...

I can submit structured data to Google Base for them to do with as they please. No doubt there will be a facetted-browser for users to search through that data and maybe even an API. But will third-party search engines be able to index any of it? Web sites can be crawled/scraped, blog publishing provides a pinging mechanism. Will Google Base provide a mechanism that doesn't fall foul of Google's terms and conditions of use?

Splogs

Well Google do seem to be trying to do things to limit the problem of spam blogs hosted on blog*spot. They've introduced a 'type in the letters' test when posting to a blog that looks suspicious. Of course if you're posting via the Blogger API then its just rejected.

More recently I note that the Atom feed for a blog*spot hosted blog has a <summary> tag with all the markup removed. By contrast a blog that is FTPed to an alternate host has a <content> tag with markup present.

UPDATE: seems to be back to normal - I know it just looks like I might have flipped the 'summary' switch but...