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.
iOS 5.1 it is stored in Library/Caches thus it is not backed up - that's why we backed it up to the Documents/Backups folder (and backed up/restore to /Library/Caches). We do _not_ set the NSURLIsExcludedFromBackupKey on the Documents/Backups folder, if the dev wanted to, they can do so using the File API's FileEntry.setMetadata function. 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. Upgrading from iOS 5.1 to 6 shouldn't be a problem since ultimately the database locations are still in Library/Caches -- we just need to set the NSUserDefaults key. This is solved by iOS 6, but we don't have a clear answer for iOS 5.1 (besides upgrading to iOS 6) -- our original fix is not tenable anymore (http://phonegap.com/2012/04/18/ios-5-1-and-the-embedded-uiwebview-with-cordova/) On Thu, Oct 18, 2012 at 8:06 AM, Michal Mocny <mmo...@chromium.org> wrote: > So there has been a lot of back and forth recently about where and how > to backup localstorage (see: > https://issues.apache.org/jira/browse/CB-1561) > > At least one users wants these to backup to iCloud -- and while I > don't see how that makes real sense, the fact that apple added a flag > to allow this in ios6 maybe signals we should allow the option. > > Given that this cannot work on versions less than 5.1, may not be > enabled on ios6, and may not work the way developers expect anyway, is > there a point? > > Shaz, would appreciate your opinion here, if you are around. > > -Michal > > On Fri, Oct 5, 2012 at 2:23 PM, Michal Mocny <mmo...@chromium.org> wrote: >> Done. >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=6e170879aa37d33701739fc3c28ed9f78156bf1f >> >> As of today we backup to a different location so as not to upset the apple >> app review overlords, and we do not backup to icloud on ios6 any more. >> >> I've added support for loading all the various old database locations the >> first time you run an upgraded app, but if there are only issues reported >> about this, send them my way! >> >> -Michal >> >> >> On Wed, Oct 3, 2012 at 4:43 PM, Dave Johnson <dave.c.john...@gmail.com> >> wrote: >>> >>> I agree backing up to iCloud seems like a bad idea. Let alone the >>> Apple policy issues. >>> >>> -d >>> >>> On Wed, Oct 3, 2012 at 10:31 PM, Michal Mocny <mmo...@google.com> wrote: >>> > === Background === >>> > >>> > In IOS5.1 moved these files from the "documents" folder to a "cache" >>> > folder, which meant they may get purged when the system decided memory >>> > was >>> > geting tight. To get around this, we implemented a manual >>> > backup/restore >>> > plugin (CDVLocalStorage). (I was not here for this work, piecing >>> > history >>> > together.) >>> > >>> > With IOS6, Apply added a new UserDefaults option >>> > (WebKitStoreWebDataForBackup) to backup these files onto iCloud, with >>> > the >>> > side effect of having persistant local storage without the need for our >>> > backup hacks/plugin. >>> > >>> > ======== >>> > >>> > Initially I used this new IOS6 feature as a means to get persistant >>> > localstorage (there was a bug to add that when I started contributing). >>> > >>> > However, its actually been against apple policy to store these files in >>> > the >>> > documents folder, and user apps are being rejected from app store, see: >>> > https://issues.apache.org/jira/browse/CB-1561. >>> > >>> > More importantly, I don't think we should want to backup these files to >>> > a >>> > users' iCloud just to get persistant storage. >>> > >>> > I think we should re-enable the plugin used for ios5.1 on ios6 and not >>> > backup to iCloud. This may have perf implications but no more-so than >>> > we >>> > have already been dealing with until now (and which I haven't >>> > benchmarked). >>> > >>> > What do others think? There are other means to fix the current issues >>> > and >>> > continue to use the next setting, so we do have options here. >> >>
