ios - 应用因违反 iCloud 存储准则而被拒绝

Question

我的应用程序最近被拒绝，因为它在将备份到 iCloud 的目录中安装了数据库。由于数据库附带了大量预先填充的数据，并且应用程序将用户生成的数据存储到同一文件中。因此，将用户生成的内容与预先填充的数据混合起来并不是苹果希望我们做的。到目前为止一切顺利。

将我的数据库分成两个，并使用 NSURLIsExcludedFromBackupKey = YES 标记带有预填充数据的存储文件。

但是，如果用户想要修改该存储中的数据，因为他发现了故障并希望对其进行修改，会发生什么情况。或者我自己进行在线更新，修改该商店的值。我该如何应对。

我是否必须删除存储文件，创建一个新文件(现在 NSURLIsExcludedFromBackupKey = NO)或从一开始就将数据库存储在/tmp 或/Library/caches 下并将其移动到/Application Support(这是支持的)自动启动)，但由于某种原因我的数据库被系统删除的威胁，/Library/caches 的情况如何？

Answer 1

如果您的应用程序实际上可以更改应用程序中的预填充数据，那么苹果将不允许您备份预填充数据，这有点令人烦恼。如果预填充的数据库很大，我可以理解他们不希望您的应用程序用 AppStore 中已有的信息浪费用户的 iCloud 空间。

伍迪对这种方法有一个好主意，但我不确定苹果会忽视这样一个事实:如果将预填充的数据复制到应用程序上用户备份的数据库，实际上会浪费同样多的空间启动。

像这样的事情怎么样:

• A:具有预填充数据的数据库，未备份
• B:已添加用户的数据库数据，已备份
• 当用户对 A 中的对象进行更改时，在 B 中创建一个新行来“覆盖”A 中的行，例如通过使用相同的 ID 或在数据库中设置一列来告诉应用程序 A 中的哪个对象应替换为 B 中的新行。

每当您需要更新应用程序时，您都会用新内容替换 DB A，仅此而已。这可能会导致与用户更改的数据发生冲突。您必须决定用户数据是否比更新的数据更重要，以及如何处理这些冲突(例如尝试同时保留它们)。

如果您需要在更新中更改 DB B 的结构，例如，如果您需要添加一列，则必须在应用程序中包含一个更新例程，以检测用户使用的是旧数据库版本，并且编写代码，在更新后首次启动时将用户数据迁移到新数据库。