让我立即解决这个问题：是的，不使用核心数据几乎肯定是错误的。但是，当我做出这些决定时，我是iOS开发的新手，我不知道我会像这样陷入困境。此外，该应用程序也打算在Android（最终）上运行，因此我尽可能避免使用特定于平台的API。
我有一个iOS应用程序，可以将数据存储在本地SQLite数据库文件中。存储在文件中的数据由用户提供，因此保持安全非常重要。我有计划“稍后再做”，后来现在在这里。我很快意识到它不会像我希望的那样直截了当......
我现在明白，无法跨设备无缝同步数据，我愿意接受这个限制，直到我设法迁移到Core Data。但是，与此同时，我至少要定期备份SQLite数据库，这样用户可以在单个设备上使用该应用程序感到安全。我以为我会这样做：
这种方法的最大问题是用户可以在多个设备上运行应用程序，因此存储在iCloud中的数据可以来自这些设备中的任何一个，但只有一个。为了解决这个问题，我想我可以在云存储中使用每个设备的唯一名称。我会使用UIDevice.identifierForVendor生成此内容。
所以我的启动逻辑是：
本地文件是否丢失或损坏，如果存在，云文件是否存在？
2.1。询问用户是否要从云文件中恢复。 真的很难让他们说不，因为这样做会失去他们所有的数据。
2.2。如果他们说是，请将云文件复制到本地文件存储。
在后台运行时，我偶尔会将数据库文件从本地复制到云存储。
我想知道这是否是一种合理的方法，直到我进行核心数据集成。还有，我可能会遗漏任何隐藏的“陷阱”吗？
更新：正如@TomHarrington在评论中指出的那样，我的数据库文件已经位于/Documents，它已备份到iTunes和任何iCloud帐户。所以我的问题变成了这个：
我应该只是确保我的数据库具有特定于设备的名称，以免被连接到同一iCloud帐户的其他设备上运行的应用程序破坏吗？
答案 0 :(得分：1)
我将回答我的问题，因为我最终沿着这条路走下去并找到了一个 MASSIVE 拦截器。 UIDevice.identifierForVendor API中存在一个错误，导致每次安装新版本的应用时都会重新生成错误！见here。这当然排除了将其用作设备标识符。 叹息
我认为我采用这种方法是SOL。相反，我可能会在第一次执行时生成GUID并使用那个作为我的标识符。问题是，我需要将 存储在未备份到iCloud的某个地方。
呃，我可能只是放弃在这里说我的应用程序无法在多个设备上运行，直到Core Data集成完成。
更新：我最初在第一次运行时生成了一个标识符，并将其存储在钥匙串中（仅作为本地条目，因此不会备份到iCloud）。