I’m seeing an error with Core Data that seems to indicate that the old database is not being deleted when I delete the app from my device. Here are the steps I’m taking to do this:
- Delete the app from my device (tap & hold on the app, then tap the delete button).
- Install the app from TestFlight.
- Run the app. It starts and runs fine – until it makes a Core Data query that causes it to crash. The root cause of the crash is ‘keypath bar not found in entity <NSSQLEntity Foo id=3>’
Now, based on the error stated in step 3, it may seem that ‘bar’ just doesn’t exist on Foo and that my issue is with the Core Data model. However, the same code runs on the Simulator without issue and even runs fine on device when connected through Xcode. (I’ve verified a number of times that the code I’m using in Xcode to run on the Simulator and device is the same as the code in my TestFlight builds.) The problem only exists when installing via TestFlight, but I see no reason to blame TestFlight for my problems.
The same issue happens for another person on my team following the same steps, so the problem is not specific to my device. The app is not using iCloud, MobileMe, or any other syncing functionality.
Is everything Core Data-related deleted when I delete the app from my device? Does Core Data deletion or initialization behavior change depending on how the app is installed on the device?
All the files may not be deleted off simulator or in the case of a development build on device. This has something to do with Xcode not wanting to have to reinstall the entire app bundle from scratch every time it builds during development. Instead of trashing everything, it just alters what was changed. This can cause problem e.g. .xcdatamodel files don’t seem to be reliably removed from the simulator when the file is removed from the build target.
However, on a release build on device, deleting the app will delete all the files in the apps sandbox i.e. everywhere the app can write.
This will not be the case on a jailbroken device.
Update:
After reading the updated parent I would note that this error:
… is generated when you try to access a keypath that the entity doesn’t support. This error almost always occurs inside the predicate of a fetch request. A common cause is trying to fetch against a transient attribute. (Fetches run against the store and transient attributes by definition do not exist in the store.)
However, I have seen exactly this sort of error crop up with the development install problems I described above.
Since this is true:
… I don’t think that:
… is really justified. If everything works unless you use TestFlight then it seems reasonable to conclude that TestFlight is triggering the problem.