iOS 10 - NSManagedObjectContext save with persistentstore

I am having an issue in iOS 10 where, after saving my NSManagedObjectContext, the data is no longer in memory. I have a NSPersistentStoreCoordinator that has an NSPersistent store that is set to a file using [myPersistentStoreCoordinator setURL:filePath forPersistentStore:myStore];


Any time I try to get any data from my managedObjectContext with [myManagedObjectContext executeFetchRequest:request error:&error]; it tries to fetch the data from the file I previously set my persistent store to.


In iOS 9.3, it just gets the data from the managedObjectContext in memory.


This is a problem for me in iOS 10 because I write out the data to the file specified for my persistentStore, then encrypt it as another file. Then I delete the original data file. So when it tries to fetch data from the file (which no longer exists), I get an "SQLite error code:6922, 'disk I/O error'".


I only want to decrypt and read the data I have written to disk when first loading it at app launch. I also only write the changes when data is saved (user clicks save). However, navigating the app requires access to the data, so having it kept in memory while the app is running is important.


Can anyone tell me what changed in iOS 10 and how to restore the desired behaviour?


XCode 8 running in iOS 9.3 simulator, everything works fine.

XCode 8 running in iOS 10 simulator, data not stored in memory, requires persistent store file.

Replies

Looks like the changes in coredata for iOS 10 for better memory management is what caused this.


My workaround is as following:


On launch, decrypt the data file, add the persistentStore to the coordinator with the path to the decrypted data file, migrate the presistentStore to the NSInMemoryStoreType, overwrite and delete the decrypted data file.


When changes are made and need to be saved, migrate the in-memory persistent store back to an NSSQLiteStoreType in a file, encrypt the data to a new file, migrate the presistentStore back to the NSInMemoryStoreType, overwrite and delete the unencrypted data file.


Will have to see over time how the performace is with this workaround. But, in my case, the data is usually only a few hundred KB.