由于涉嫌违反iCloud数据存储准则，最近拒绝了对我的一个应用程序进行的重要错误修正更新。
这是我的应用存储数据的方式(自2009年批准第一版应用以来，这一直不是问题):
由于同样的原因，今年早些时候的更新被拒绝了，但是当我给他们上面的解释时，应用程序的状态从“已拒绝”更改为“正在审核”，再更改为“正在处理App Store”。他们没有给我任何解释，所以我认为这只是审稿人的一种误解。
这次，审阅者通过简单地说非用户生成的数据不应该存储在iCloud中，而我的更新仍处于“已拒绝”状态来回应我的解释。
但是我不明白我应该在这里做什么。因为所有用户的工作都保存在数据库中，所以我不能选择将其从iCloud备份中排除或将其存储在Cache文件夹中。而且，我无法真正将“用户生成的”数据与“非用户生成的”数据完全区分开，因为该应用程序是在同一数据库文件中工作的。尽管数据库的文件名和目录位置将保持不变，但最初的非用户生成数据将被用户自己的数据快速替换。
即使数据库中没有示例数据，任何数据库支持的应用程序启动时仍将必须生成一个空数据库-即使它持有的唯一内容是该应用程序的数据库架构。
这肯定是一个非常普遍的问题，但是不幸的是，我不能关闭备份功能-用户对他们存储在我的应用程序中的数据进行了大量工作，而iCloud备份对他们来说非常重要。
我现在有什么选择？这是我所看到的:
有人有什么建议吗？我必须想象，还有许多其他应用程序都使用与我相同的方式使用数据库，但是没有选择禁用备份。
同样令人沮丧的是，我所做的任何更改都需要另一轮测试和应用审查，这将使我的重要更新再推迟2-3周。 :/
更新:可能还有另一种选择:我可以简单地将文件保存为
Library/而不是Documents/，因为它们的问题似乎专门与使用Documents文件夹有关？如果文件存储在Library/中，是否将对其进行备份？更新2 :我发现最令人困惑的是，任何数据库支持的应用程序(即使我假设它使用的是Core Data)都必须创建一个至少包含该应用程序架构的数据库文件。问题仅仅是我的数据库太大吗？因为我看不到任何数据库支持的应用程序如何避免在启动时不得不创建数据库。
更新3 :我使用的是自定义SQLite交互层-不是Core Data。同样，示例数据由启动器图像组成，用户在开始使用该应用程序时可能会最终将其删除。
最佳答案
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将由您的数据库支持。通过这种方式减少数据存储，您应该能够获得批准，因为您不会在手机上存储相对大量的数据。图像也可以通过这种方式包含在应用程序 bundle 包中，根本不需要重复。
关于ios - iPhone应用程序因iCloud数据存储准则而被拒绝，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11374969/