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...
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...
Comments