ios - iPhone App Rejected because of iCloud Data Storage Guidelines -
a critical bugfix update 1 of apps rejected due alleged violation of icloud data storage guidelines.
here's how app stores data (hasn't been problem since first version of app approved in 2009):
- on startup, copies "starter" sqlite3 database app bundle documents folder.
- the database contains basic schema , example data user can see how use app. it's small - under 3mb.
- the user's future work saved in database file. may delete or keep samples, may add tons of own data, database file there.
an update earlier year rejected same reason, when gave them explanation above, app status changed "rejected" "in review" "processing app store." didn't send me explanation, thought misunderstanding on reviewer's part.
this time, reviewer responded explanation saying non-user-generated data shouldn't stored in icloud , update remains in "rejected" state.
but don't understand i'm supposed here. because of user's work kept in database, it's not option me exclude icloud backup or store in cache folder. also, can't cleanly separate "user-generated" "non-user-generated" data because app works same database file. initial, non-user-generated data replaced user's own data, though filename , directory location of database remain same.
and if there no sample data in database, database-backed app still have generate empty database when starts - if thing holds app's database schema.
this must common problem, unfortunately it's not okay me turn off backup - users put lot of work data store in app, , icloud backup important them.
what options have @ point? here's can see:
contact apple again , try explain what's going on.
can set file's backup attribute no , toggle yes when user makes first change? okay technically , okay apple?
remove example data database. bad usability , increase support load, i'm willing if update approved. however, i'll still have create stub database @ startup hold empty database schema, i'm not sure if make difference in approval process.
cry.
anyone have advice? have imagine there lots of other apps use database same way mine does, don't have option of disabling backup.
it's depressing changes make require round of testing , app review, set critical update additional 2 - 3 weeks. :/
update: there may option: can save file in library/
instead of documents/
, since problem seems use of documents folder? file backed if it's stored in library/
?
update 2: thing find confusing database-backed app (even if uses core data, assume) have create database file containing @ least app's schema. problem size of database big? because can't see how database-backed application can avoid having create database @ startup.
update 3: i'm using custom sqlite interaction layer - not core data. also, example data consists of starter images, user end deleting start using app.
3mb seems quite lot of sample data stored in database. if pull out images , store references images in database instead should able usage down lot. can change database's image getter code this:
- (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 else, uuid maybe? nsstring *filepath = [imagelibrarypath stringbyaddingpathcomponent:imagename]; [imagedata writetofile:filepath atomically:yes]; // maybe dispatch_async background? self.filename = filename; }
the self.filename
backed database.
by reducing data storage in way should able approved not storing relatively large amounts of data on phone. images can in app bundle way , not need duplicated @ all.
Comments
Post a Comment