CODEWITHSUNDEEP
ioscore-data
Bernd Rabe
Bernd Rabe

Reputation: 790

App rejected due to violating iCloud storage guidelines

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.

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.

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?

Upvotes: 3

Views: 513

Answers (2)

jake_hetfield
jake_hetfield

Reputation: 3398

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 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.

What about something like this:

  • 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.

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).

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.

Upvotes: 2

Woody
Woody

Reputation: 5130

When you startup, if the user database is unpopulated you could copy the data across from the pre-populated datatabse, and maybe give the user an option to reset defaults which does the same again?

Upvotes: 0

Related Questions