iOS 应用因 2.23 被拒绝 - iOS 数据存储准则

iOS App Rejection due to 2.23 - iOS Data Storage Guidelines

这是来自 Apple 的关于拒绝的消息:

2.23 - Apps must follow the iOS Data Storage Guidelines or they will be rejected 2.23 Details

On launch and content download, your app stores 6.5 MB, which does not comply with the iOS Data Storage Guidelines.

Next Steps

Please verify that only the content that the user creates using your app, e.g., documents, new files, edits, etc. is backed up by iCloud as required by the iOS Data Storage Guidelines. Also, check that any temporary files used by your app are only stored in the /tmp directory; please remember to remove or delete the files stored in this location when it is determined they are no longer needed.

Data that can be recreated but must persist for proper functioning of your app - or because users expect it to be available for offline use - should be marked with the "do not back up" attribute. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCRUFLIsExcludedFromBackupKey attribute.

我检查了我的应用程序的设备和模拟器数据文件。我发现如果应用程序使用了一段时间,它的总应用程序数据可以在启动时存储 5-6 MB。但是我卸载并重新安装了应用程序并再次检查,我在应用程序启动时看到 ~3MB 数据存储。

我没有存储任何 Core Data 数据库或任何其他数据库文件。但我已经意识到 Google Analytics 和 Google 跟踪代码管理器 在此路径上存储了一些 sqlite 数据:"AppData/Library"。我的意思是它不存储在这条路径上:"AppData/Library/Caches"。它对 iOS 数据存储指南有什么影响吗?

顺便说一句,iCloud 已禁用应用程序。

我还使用 SDWebImage 下载图像,它在启动时存储了将近 3 MB 的图像,并将图像数据存储在这个路径上:"AppData/Library/Caches"

您知道我应该如何处理这个问题吗?

我昨天刚收到同样的拒绝信息。

我在application:didFinishLaunchingWithOptions:中使用以下代码来查看我的应用程序在文档文件夹中有什么以及关于 iCloud 备份的每个项目的权限是什么:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *basePath = ([paths count] > 0) ? [paths objectAtIndex:0] : nil;
NSArray *documents = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:basePath error:nil];
NSURL *URL;
NSString *completeFilePath;
for (NSString *file in documents) {
    completeFilePath = [NSString stringWithFormat:@"%@/%@", basePath, file];
    URL = [NSURL fileURLWithPath:completeFilePath];
    NSLog(@"File %@  is excluded from backup %@", file, [URL resourceValuesForKeys:[NSArray arrayWithObject:NSURLIsExcludedFromBackupKey] error:nil]);
}

我在该文件夹中有一些文件正在与 iCloud 同步。因此,我没有将这些文件保存在另一个地方,而是将 NSURLIsExcludedFromBackupKey 键的资源值设置为 YES 以排除这些文件被 iCloud 备份,如下所示:

NSURL *URL = [NSURL fileURLWithPath:photoPath];
[URL setResourceValue:@(YES) forKey:NSURLIsExcludedFromBackupKey error:nil];

我今天再次发送我的应用程序,看看是否有效。

希望对您有所帮助。

运行 最近在同一个问题中,刚刚翻译了 Glauco 对 Swift 的回答(尽管它可能会写得更多 Swiftly)

let directories = NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory.DocumentDirectory, NSSearchPathDomainMask.AllDomainsMask, true)
    if let documentDirectory = directories.first {
        do {
            let documents = try NSFileManager.defaultManager().contentsOfDirectoryAtPath(documentDirectory)
            for files in documents {
                let urlForm = NSURL.fileURLWithPath(documentDirectory + "/" + files)
                do {
                    try print("\(files): \(urlForm.resourceValuesForKeys([NSURLIsExcludedFromBackupKey]))")
                } catch {
                    print("can't find key")
                }
            }
        } catch {
            print("can't retrieve contents")
        }
    }

设置资源值的代码

let urlToExclude = NSURL.fileURLWithPath(quoteSavePath!)
    do {
        try urlToExclude.setResourceValue(NSNumber(bool: true), forKey: NSURLIsExcludedFromBackupKey)
    } catch { print("failed to set resource value") }

最近,我们被 Apple Review Team 以同样的问题拒绝了,

在启动和内容下载时,您的应用程序会在用户的 iCloud 上存储 9.65MB,这不符合 iOS 数据存储指南。

他们建议遵循上述问题中提到的相同后续步骤

在我们的例子中,我们已经在下载内容时在代码中设置了 NSURLIsExcludedFromBackupKey。我们通知审核团队我们已经在这样做,因此他们将我们重定向到 Apple 开发人员技术支持 (DTS) 以更好地解决该问题。

DTS 回复说是我们的 AppIcon 文件导致了这个问题。

AppIcons 正在 iCloud 中备份,因为 Apple 要求在下载应用程序时在设备上显示图标。事实证明,我们的应用程序的 AppIcons 文件太大而导致被拒绝,因为它正在将大量数据备份到 iCloud。 App Review 团队没有清楚地向我们传达这一点,因为他们中的一些人不知道跟踪 AppIcons 的新工具更改。

现在我们知道了原因,我们使用 ImageOptim 优化了我们的图标并将大小最小化到 75KB。

我们提交了我们的应用程序,希望它能在 1 到 2 天内获得批准。 :)

我希望这对遇到同样问题的人有所帮助。 :)