> On Thu, Oct 18, 2012 at 1:55 PM, Shazron <shaz...@gmail.com> wrote: >> To recap: >> >> iOS 6 indeed does solve this problem with the NSUserDefaults key >> "WebKitStoreWebDataForBackup" - which I think the web data is stored >> in Library/Caches as changed by iOS 5.1. > > What do you mean by "ios6 does solve this problem"? > > The WebKitStoreWebDataForBackup flag changes the LocalStorage location > from /Library/Caches to /Library/WebKit/LocalStorage (ie, back to > where it was before ios5.1 moved it to Cache folder). Setting this > flag means LocalStorage persists (great) but also backs up to iCloud > (may not be desired -- and arguably should never be desired).
Does it back up to iCloud though? I wasn't sure. >> CB-1561 (Apple rejection) could be solved by them setting the metadata >> bit. But if they want it to be backed up by iCloud they shouldn't do >> set that bit - but then if they _don't_ set that bit -- rejection. > > If not setting that bit causes rejection, then seems we should just > set it by default. Somehow apps have managed to sneak by the review > process until now (perhaps the changes to ios6 have changed the review > process?). It might be a perception problem -- the reviewers see a bunch of .db files that do not seem "user created" and taking up a lot of space, and think it's app data that can be recreated. I don't recall the actual reason why the bit wasn't set in the first place - but it probably was my reasoning that the user should actively know what is happening with this data and use the setMetadata function if they _don't_ want it to be backed up (so it is backed up by default -- iCloud plus iTunes sync). That and it wasn't documented adequately by me probably resulted in a lot of headache.