How to Test Core Data Migration With an App Already in the App Store?

Question

We have an app that is currently in the app store. It uses Core Data as its persistence mechanism. We have a new version ready to go, and it has some schema changes. Specifically, we have added 1 new entity and added a new attribute to an existing entity. From my understanding and reading, this is one of the most simple migrations that can occur. There are no field deletions, and no relationships to change. The data model consists of 5 entities with no relationships at all.

We have versioned the data model, and created an .xcmappingmodel to handle the migration. We are handling the migration by adding the following options to the creation of the PersistentStoreCoordinator:

NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
                     [NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption, nil];

Currently, we have tested successfully with several members of the team using the following process:

1. Delete all test versions of the app from the device and from iTunes
2. Go to the app store and download the current version
3. Make some changes to the app that will prove the migration was successful
4. Drag the new binary (signed with the same bundle identifier) into iTunes and sync
5. Load the new version on the device, verify that the changes made in the previous version are still present, and that the app does not crash

My question is this: Is there an easier/better way to test this? Our concern is that once the app goes out the door, there is no other way to ensure our users have the best experience possible.

Canard

Answer 1

I've been using Core Data for my app and upgraded about 7 times, migrating from old models to new models.

Whenever, I am prepared to release the next version, I always test migration by using Model Mapping. As long as I made every entity and attribute of source model is matched against corresponding entity and attribute of destination model, I've experienced no problem.

Testing with your own project files are just as same as testing released ones that are distributed to the customers, so you don't have to worry if your test for migrating old model to new model is valid.

In other words, your project bundle's target, which is going to be archived and submitted, is same as what's being downloaded by the customer.

I'm pretty confident this is the case, since I've done testing with different versions of my app with no problem.

Misvalue

Thanks. I thought this was the case. I just wanted to make sure we were going about it the right way. – Canard

Answer 2

Yes.

I hope you're managing your source code in a source code management system. If not, start as soon as possible. Xcode 4 provides git built in, if you don't have another, use that one.

If you have the old source code, keep two different directories, the 1.0 build (that's now in the store), and the 1.1 build. If you can manipulate the data that will be effected in the simulator, that's ideal.

You're storing your core data in a file in the app, it's now somewhere like /Users/bshirley/Library/Application\ Support/iPhone\ Simulator/4.3.2/Applications/6D18BD0E-70C1-41FB-9BE8-F736CAAA9FFC/Documents/MyApp.sqlite

You can copy that out of the directory, add it as a resource in the new app, and perform the conversion every time you freshly install on the sim/device. You can drop in any new version of the old format to test out different data sets.

Overabundance

we've been using source control since day 1. I'm familiar with the location of the actual db file and where I can grab it. Pretty often, I have to load up the db (using base.app) to ensure changes were made, or values were written properly. But does this method get us a valid test against the current version in the app store? Also, does this method lend itself to beta testers being able to test upgrades for us as well? – Canard

It's definitely good as far as v. the version in the app store. You don't need to be downloading that version - running the same build, whether sim or device is fine. You'll have to determine what possible test cases, knowing your model, you should run at the auto-migration to cover your bases. As far as Beta testers, they'll only get the one test of the auto-upgrade normally. Requiring them to delete, download, rebuild, and upgrade again is likely undesirable. – Overabundance

As you mentioned, your migration seems minimal, there's not a lot that should effect it. I'd think the biggest issue would be handling null references to the new attribute/entity. – Overabundance