Daring Fireball Strikes OpenClip and iPhone Cut and Paste
We recently covered the new OpenClip project, and expansion of what was first demonstrated with MagicPad, and we liked both their implementation and their moxy in trying to pip Apple to the cut and paste post. Not everyone was as entirely impressed as us, however. John Gruber of Daring Fireball questioned whether or not the developers were really respecting the App Store SDK agreement. Since OpenClip aware applications write to their own sandbox'd Documents directory, but read the last-modified chunk from other applications Documents directory, Gruber considers it more of a loophole, and cites Apple's iPhone OS Programming Guide:
Not simply that no other application can write to, but which no other application can access. That this restriction is not yet enforced at a technical level (such as is the case with an app attempting to write outside its own sandbox) does not mean it’s permitted.
Worse yet, Gruber points out that the current Beta 4 of the upcoming 2.1 firmware DOES enforce complete denial-of-access to other application's Documents directory:
The OpenClip demo apps, which work as advertised on iPhone OS 2.0.2, do not work in the current 2.1 beta, because apps are no longer able to read or even see other apps’ sandboxes.3 To be clear, this change is clearly not in response to OpenClip; Apple began seeding the 2.1 betas with these tightened sandbox restrictions before OpenClip debuted, and the iPhone OS Programming Guide has stated all along that apps can’t “access” the contents of other sandboxes.
However, I'm not entirely certain any of that matters. OpenClip, based on my understanding, was never intended to be a long-term solution, merely a proof-of-concept to show that cut, copy, and paste could be done in an elegant manner on the iPhone, to keep a spotlight on the continued lack of cut, copy, and paste support from Apple, and to encourage the discussion of the issue and implementation.
In that regard, I think they've already succeeded.