If you’re looking for the quick and dirty solution to reseting Core Data in simulator or your development device, the easiest way is to simply delete the app and build again. This will install with empty SQL stores, but will also wipe
UserDefaults and other data stores that are commonly used for settings and the like.
If you want to change or wipe the data on a device that is already pushed into production, you will need to come up with a migration plan, which could involve a method to rename tables, columns, etc and do pruning wherever necessary. Migration plans are different case to case, so there is no one-size-fits-all, but generally it’s better to prompt the user that a migration will occur, and possibly even ask them to accept/deny the migration (especially for legal purposes).
Migration Best Practices
This is by far the best approach. Generally, if you follow these steps as a migration plan, your code and data will remain clean and you will be able to easily reuse many aspects of this functionality again in future versions of your application:
- Define a class that will perform your migrations. Sometimes it’s nice to create an abstract class that performs renames, callbacks, or supports rollbacks in the event of failure. There are also a number of cocoapods that help make this easier.
- Create a new data store. Naming the data store after the release version of your app is generally a great way to go.
- Invoke an initializer of your migration class which can loop through tables then through rows in order to invoke a sanitization method on a per-column basis.
- Each column should be scrubbed to perform any changes such as new typecasting, removing of spaces, adjusting character length, etc.
- You should use an
UserDefaultsetting to specify which database version to use. This way, if the database migration fails, you could essentially rollback to the old data store and fix bugs for a future release.