iPhone 应用因 iCloud 数据存储指南而被拒绝

Question

由于涉嫌违反 iCloud 数据存储指南，我最近拒绝对我的一个应用进行重大错误修复更新。

以下是我的应用程序存储数据的方式（自 2009 年我的应用程序的第一个版本获得批准以来，这一直不是问题）：

1. 在启动时，它会将“starter”SQLite3 数据库从应用程序包复制到 Documents 文件夹。
2. 数据库包含基本架构和一些示例数据，因此用户可以了解如何使用该应用程序。它很小 - 不到 3MB。
3. 然后，用户未来的工作将仅保存在此数据库文件中。他们可能会删除或保留样本，可能会添加大量自己的数据，但该数据库文件将始终存在。

今年早些时候的一次更新因为同样的原因被拒绝了，但是当我给他们上面的解释时，应用程序状态从“拒绝”变为“审查中”再到“正在处理 App Store”。他们没有给我任何解释，所以我认为这只是审稿人的误解。

这一次，审阅者对我的解释作出了回应，只是说非用户生成的数据不应存储在 iCloud 中，我的更新仍处于“拒绝”状态。

但我不明白我应该在这里做什么。因为所有用户的工作都保存在数据库中，所以我不能将其从 iCloud 备份中排除或将其存储在缓存文件夹中。此外，我无法真正将“用户生成”数据与“非用户生成”数据完全分开，因为该应用程序使用同一个数据库文件。初始的、非用户生成的数据将很快被用户自己的数据替换，但数据库的文件名和目录位置将保持不变。

即使数据库中没有示例数据，任何由数据库支持的应用程序在启动时仍必须生成一个空数据库 - 即使它唯一保存的是应用程序的数据库架构。

这一定是一个很常见的问题，但不幸的是，我不能只关闭备份——用户在他们存储在我的应用程序中的数据上投入了大量工作，而 iCloud 备份对他们来说非常重要。

此时我有什么选择？这是我能看到的：

1. 再次联系 Apple 并尝试解释发生了什么。

2. 我能否将文件的备份属性设置为 NO，然后仅在用户进行第一次更改时才将其切换为 YES？这在技术上是否可行，对 Apple 是否可行？

3. 从数据库中删除我的示例数据。这对可用性真的很不利，并且会增加我的支持负担，但如果它能让我的更新获得批准，我愿意这样做。但是，我仍然需要在启动时创建一个存根数据库来保存空的数据库架构，所以我不确定这是否会对审批流程产生影响。

4. 哭泣。

有人有什么建议吗？我不得不想象有很多其他应用程序使用数据库的方式与我的方式相同，但没有仅禁用备份的选项。

同样令人沮丧的是，我所做的任何更改都需要另一轮测试和应用审查，这将使我的关键更新延迟 2 到 3 周。 ：/

更新：可能还有另一种选择：我可以简单地将文件保存在Library/ 而不是Documents/，因为他们的问题似乎与使用 Documents 文件夹有关吗？如果文件存储在Library/，是否会备份文件？

更新 2：我发现最令人困惑的是任何数据库支持的应用程序（即使它使用 Core Data，我假设）都必须创建一个至少包含应用程序架构的数据库文件.问题只是我的数据库太大了吗？因为我看不出任何支持数据库的应用程序如何避免在启动时创建数据库。

更新 3：我使用的是自定义 SQLite 交互层 - 而不是 Core Data。此外，示例数据包含初始图像，用户在开始使用应用程序时可能最终会删除这些图像。

Answer 1

3MB 似乎是存储在数据库中的大量样本数据。如果您提取图像并将对图像的引用存储在数据库中，那么您应该能够大大降低这种使用量。然后，您可以将数据库的图像获取器代码更改为以下内容：

- (UIImage *)image
{
    NSString *imageName = self.imageName;
    UIImage *image = [UIImage imageNamed:imageName];
    if (!image)
    {
        NSString *imageLibraryPath = ...;
        image = [UIImage imageWithPath:[imageLibraryPath stringByAddingPathComponent:imageName]];
    }
    return image;
}

- (void)setImage:(UIImage *)image
{
    [self setImageData:UIImagePNGRepresentation(image)];
}

- (void)setImageData:(NSData *)imageData
{
    NSString *imageLibraryPath = ...;
    NSString *fileName = self.uniqueId; //or something else, UUID maybe?
    NSString *filePath = [imageLibraryPath stringByAddingPathComponent:imageName];
    [imageData writeToFile:filePath atomically:YES]; // maybe dispatch_async this into the background?
    self.fileName = fileName;
}

self.fileName 将由您的数据库支持。

通过以这种方式减少数据存储，您应该能够获得批准，因为您不会在手机上存储相对大量的数据。图片也可以通过这种方式放在 app bundle 中，根本不需要复制。

Answer 2

我有一个非常愚蠢的想法。但也许它是有效的。

您可以在启动时显示一个弹出窗口，询问“您希望我创建一些演示数据”。当用户点击“是”时，其用户生成数据。

Answer 3

一种解决方法是从包中读取 SQL 文件，直到用户尝试编辑某些内容。然后复制过来。由于文件很小，它甚至不需要微调器。

我遇到了这个确切的问题 最近的应用。在我们的例子中，我们使用核心数据并在启动时复制 SQL 文件。

不幸的是，您必须以 iOS 5 为目标。

https://developer.apple.com/library/ios/qa/qa1719/_index.html

Answer 4

只需添加以下属性，Apple就会让你通过（如果你没有使用

    #include <sys/xattr.h>
    ...
    - (BOOL)addSkipBackupAttributeToItemAtURL:(NSURL *)URL
    {
    int result = -1;
    @try {
            const char* filePath = [[URL path] fileSystemRepresentation];
            const char* attrName = "com.apple.MobileBackup";
            u_int8_t attrValue = 1;
            result = setxattr(filePath, attrName, &attrValue, sizeof(attrValue), 0, 0);
    } @catch (NSException * e) {
            DebugLog(@"Exception: %@", e);
    }
    return result == 0;
    }

    - (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
    ... 
    NSURL *storeUrl = [NSURL fileURLWithPath:storePath];
    [self addSkipBackupAttributeToItemAtURL:storeUrl];
    ...

Answer 5

CoreData 和两个持久存储应该是要走的路。 但是对你来说，在第一次复制文件时设置 com.apple.MobileBackup 文件属性。在用户进行第一次修改后取消设置

Answer 6

作为最终解决方案，我建议使用 CoreData，将您的罐装数据作为额外的只读持久存储。

但是，与此同时，您需要一个简单、快速的解决方案。创建一个简单的屏幕，将样本数据加载到用户的数据库中。在“系统”或“工具”屏幕中放置一个链接，以便随时完成。

不过，特别是在应用程序首次运行时将其显示出来。您是在询问用户是否需要在文档中包含样本数据以及数据的大小，因此他们是创建文档的人。还提到可以随时删除或替换示例数据。

这应该会让你通过审查。

Answer 7

使用您的“私有”SQL 数据访问层

由于您使用的不是Core Data，而是自定义访问层，我只能建议不要将“初始种子”数据库放在iCloud文件夹中，而是编写一个在运行时生成它的自定义过程（例如，当您首先启动应用程序）。

最好的方法应该是将您的真实 SQL 文件放在通用应用程序包中，在 iCloud 共享文件夹之外。通过您的程序，您必须读取此文件的所有内容并在共享文件夹中重新创建一个克隆，以便此新文件将显示为用户生成的内容而不是捆绑的内容。这将需要一些无用开销，但我认为这是避免Apple拒绝您的应用所必需的。

如果可能的话，我建议您不要备份所有图像并将它们留在主包中，因为它们已经存在于每个下载的应用程序中，然后会无用地占用 iCloud 上的宝贵空间。尝试仅将绝对必要的内容放入 iCloud。

如果您计划同时使用 Core Data 和 iCloud。

首先，在 iCloud 中放置自定义 SQLite3 数据库文件是危险的，原因有两个，首先是如果您的应用在不同的平台上使用，您将永远无法正确处理不同数据之间的合并问题。设备并发。

我不能在这里给你一个完整的解决方案，因为它需要太多的时间和空间。但我建议你看看今年 Apple WWDC 的 Session 227 演讲。他们谈到一起使用 Core Data 和 iCloud，还解决了您现在面临的相同问题（即通过 iCloud 进行初始数据库播种和同步）。如果您通过 Apple 开发者门户访问 WWDC 页面，您将能够获得示例项目的完整副本。

Answer 8

如果您使用的是 Core Data，您可以将示例数据保存在 app bundle 中。在与 docs 目录中的读/写存储相同的协调器上将其作为只读持久存储打开，Core Data 将确保保存时内容保持在正确的位置。 WWDC 2012 的“使用核心数据的最佳实践”视频对此进行了解释。

如果您直接使用 SQLite，这并不容易，但您可以实现自己的逻辑来做同样的事情。