Apple 文档似乎一致声明，用户生成的文档要么全部存储在本地，要么全部存储在 iCloud 上。这是此 iOS 页面中的一个示例（对All的强调是他们的）：
应用程序的所有文档都存储在本地沙箱或 iCloud 容器目录中。用户不应该能够选择单个文档存储在 iCloud 中。
我想允许用户单独管理文档：也许他们希望一个在本地（从他们的 iCloud 配额中节省空间），另一个在 iCloud 上以便他们可以跨设备操作它，另一个在 DropBox 上以便他们可以将其复制到朋友的帐户中或手动备份，甚至可以在外部进行编辑。全有或全无的方法实际上会妨碍灵活性，尤其是当我介绍DropBox sync时。就我而言，个人选择也使 UI 更简单。
所以问题是：如果我坚持我的计划，允许用户为每个文档选择他们的存储偏好（本地、iCloud 和很快的 DropBox），我会在审阅时遇到麻烦吗？我还没有找到具体的指导方针。编辑：指南甚至都没有提到 iCloud。
这是应该的，而不是必须的（就像您应该支持 iPad 上的所有方向一样，但我认为如果 UI 需要完全返工，它们不会强迫您这样做）。如果你有一个足够引人注目的用例和一个不笨拙的 UI，我怀疑他们会让它通过，但我还没有测试过。
如果它不在审查指南中，那么除了对“可用性”的任何要求之外，我怀疑它是拒绝的理由——但老实说，考虑到 UI 的平均质量，我不会太担心。
（实际上，对该指南的严格解释是，您不应该使用 Dropbox/Google Drive/etc/roll-your-own-cloud-storage，但除非他们邀请反垄断诉讼，否则这几乎肯定不是意图。 )
我为一个带有 iCloud 的应用程序做了很多测试。我一开始的假设是，无论一切是否都在 iCloud 中，对用户来说都是透明的，否则苹果为什么会建议这种方法？
不幸的是，他们在推出之前没有对其进行全面测试。我在 iOS 4 和 5 的 iCloud 和 UIDocument 中遇到了很多问题（许多奇怪的崩溃的雷达条目）。事实上，我可能将一半的开发时间都花在了这个问题上，而不是让应用程序变得更好。
无论如何，最重要的是，当访问仅在云上运行的文档时，我的应用程序要慢得多。Apple 确实尝试在 Mobile Documents 目录中缓存文档。关于如何确定缓存状态的信息很少，因此尝试解决不可用的文档或速度缓慢的问题。UI 最终在 UITableViews 中非常生涩，或者在系统库中彻底崩溃。
所以，底线是我的应用程序将所有内容存储在本地。如果用户进行了更改，应用程序会将其复制到 iCloud 本身并运行后台进程以监控文档在云中的状态。它还手动传输由 iCloud 上的另一台设备更改的文件，以保持一切同步，再次在后台进程中。
我没有收到苹果评论家的任何抱怨。如果我这样做了，我会将它们指向许多雷达条目。