应用程式因违反iCloud储存空间指南而被拒绝 [英] App rejected due to violating iCloud storage guidelines
问题描述
我的应用程式最近遭到拒绝，是因为它会在备份至iCloud的目录中安装资料库。由于数据库带有大量预填充的数据，应用程序将用户生成的数据存储到同一个文件中。
因此，将用户生成的内容与预填充的数据混合不是苹果想要我们做的。
到目前为止很好。
My app was rejected recently due to the fact that it installs a database within a directory which will be backed up to iCloud. As the database comes with a lot of prepopulated data and the app stores user generated data into the same file. So mixing up user-generated-content with prepopulated data is not was Apple wants us to do. So far so good.
将我的数据库分成两个，并使用NSURLIsExcludedFromBackupKey = YES的预填充数据标记商店文件。
Separate my database into two and mark the store file with the prepopulated data with NSURLIsExcludedFromBackupKey = YES.
但是，如果用户想要修改该商店中的数据，会发生什么，因为他发现了一个失败并希望修改它。
或者我自己在线更新，修改与该商店的价值。
But what happens if the user wants to modify the data in that store, because he found a failure and wish to modify it. Or myself make an online update available which modifies values with that store. How do I cope with that.
我必须删除存储文件，创建一个新文件（现在使用NSURLIsExcludedFromBackupKey = NO）或存储数据库在/ tmp或/ Library /缓存从一开始，并将其移动到/应用程序支持（它是自动备份），但威胁我的数据库正在被系统删除的某些原因为/ Library / caches？
Do I have to delete the store file, create a new one (now with NSURLIsExcludedFromBackupKey = NO) or store the database under /tmp or /Library/caches right from the beginning and move it into /Application Support (which is backed up automatically) but with the threat that my database is being removed by the system for some reason what is the case for /Library/caches?
推荐答案
这是一个有点恼人的苹果不会允许你备份预填充数据，如果你的应用程序是您可以实际更改应用程序中预填充的数据。如果预填充的数据库很大，我可以理解，他们不希望你的应用程序浪费用户的iCloud空间与已经在AppStore的信息。
It is a bit annoying that Apple will not allow you to backup prepopulated data if your app is of the kind where you could actually change the prepopulated data in the app. If the prepopulated database is big, I can however understand that they don't want your app to waste the user´s iCloud space with information that is already in the AppStore.
Woody有一个好主意的方法，但我不知道苹果会从实际上浪费，就像同样多的空间，如果你复制预先填充的数据到应用程序启动时用户备份的数据库的事实。
Woody has a good idea on the approach, but I'm not sure Apple would look away from the fact that you are actually wasting just as much space if you copy the prepopulated data to the user-backed-up DB on app startup.
这样的东西：
- strong> DB DB用户添加了
数据，已备份 - 当用户对A中的对象进行更改时，在B中创建一个新行，覆盖A中的行，例如使用相同的ID或在DB中有一个列，告诉应用程序哪个对象
- A: DB with pre-populated data, not backed up
- B: DB with user added data, backed up
- When user make changes to object in A, crete a new row in B that "overrides" the row in A, for example by using the same ID or by having a column in the DB that tells the app which object in A should be replaced by the new row in B.
每当您需要更新应用程式时，都会将DB A换成新的内容就是这样。这可能会导致与用户更改的数据冲突。您必须决定用户数据是否比更新的数据更重要，以及如何处理这些冲突（例如，尝试保留这两个冲突）。
Whenever you need to update your app, you will replace DB A with new content and that's it. This could lead to conflicts with the data that the user has changed. You will have to decide whether the user data is more important than the updated data, and how to handle these conflicts (for example by trying to keep them both).
如果您需要在更新中更改DB B的结构，例如，如果您需要添加列，则必须在应用程序中包含一个更新例程，以检测用户是否具有旧的DB版本并编写代码以进行迁移在更新后首次启动时将用户数据更新到新数据库。
If you need to change the structure of DB B in an update, for example if you need to add a column, you will have to include an update routine in your app that detects that the user is having an old DB version and write code to migrate the user data to the new database on first startup after the update.
这篇关于应用程式因违反iCloud储存空间指南而被拒绝的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
