3

In the latest version of my app, I added 1 new column to an existing table. Nothing major, just a simple flag. I bumped the data model version and set it to be the active model and I've been using the automatic lightweight migration strategy successfully for the last several app updates.

A small minority of users have reported that after upgrading to the latest version of my app, they lose all their data and the app crashes any time it tries to write/read to/from CoreData. I cannot replicate the issue.

Why would auto migration work for most, but not all users?

Answer

In this specific instance, the issue ended up being that I had accidentally modified an xcdatamodel file that was several versions old without knowing it. When I released a new version of the app, there were a handful of users that had not updated for a very long time, and therefore the "most recent" version of the xcdatamodel they had was the same as the file that I accidentally changed. When migration tried to happen on their devices it choked because the version of the data model file that it wanted to base migration on had been modified.

To fix this, I had to identify what I changed in the old xcdatamodel file, undo the change, and release an app update. Once users affected by this updated to the newest version, migration worked.

Additional Information:

The only thing they all seem to have in common is they are all running iOS 6.1.3. I cannot replicate this myself. I have a device running iOS 6.1.3 but no matter how many times I do the upgrade from one version of my app to the next, it works. I've even tried skipping a couple versions and upgrading from an old one to the newest and it worked fine.

For what it's worth, I'm using the auto-migration strategy outlined in this post and it has been working fine for the last 8 or 10 app updates, including some major new things added to/removed from my CoreData model.

Community
  • 1
  • 1
DiscDev
  • 38,652
  • 20
  • 117
  • 133
  • So, you're complaining that it all works? Or what are you trying to accomplish? – Scott Berrevoets May 29 '13 at 23:05
  • I bolded the important part so people don't skip over it :) – DiscDev May 29 '13 at 23:09
  • My bad, for some reason I read 'users' as 'other developers'. Any chance you have more information about the circumstances? Are they all upgrading from the latest app version, how much data was in the store, that kind of stuff? – Scott Berrevoets May 29 '13 at 23:14
  • 1
    Usually these types of things come down to a data bug. There is some data that the user has in their persistent store that is not playing nice with the migration. Obtaining a copy of the persistent store file from an affected device is probably your best bet to resolving this. If you can get a user to help you out here, you could create an ad-hoc build for them that has a mechanism that will upload their persistent store file to something like Amazon S3 for you to analyze. – Chris Wagner May 29 '13 at 23:14
  • Hey Chris - could you be a tiny bit more specific about what kinds of bad data this might happen with? One of the main things my app does is downloads new data from my server when it starts up and shoves it into CoreData - at one point some non-ascii characters may or may not have snuck in to that file - but I'm not completely sure. Are those the kinds of "bad data" you are referring to? Also, I've been trying to get people to help me out, but all of them have been quite fine to uninstall/reinstall the app and lose their data instead of going to the trouble to help me :( – DiscDev May 29 '13 at 23:16
  • Is any of the data user generated? Does the size of the persistent store vary vastly across users? What migration steps are necessary for this upgrade? How did your schema change? This could be helpful in narrowing down possibilities. – Chris Wagner May 29 '13 at 23:18
  • Some data is user generated, yes. Mostly things like typing in names for various items. I would say that the size of the store could vary between users, but not more than a few MB. Most of the data is text. – DiscDev May 29 '13 at 23:19
  • Is your migration happening at app launch? Apple kind of sets you up for failure with their templates here... If the migration takes too long the watchdog will kill your app and the migration won't finish. – Chris Wagner May 29 '13 at 23:22
  • No, it's not happening at launch. I'm using a singleton to get a handle to my DB operations, so the first time that my app tries to access the DB (which is not at launch, but after the user navigates to a certain page) is when the migration would happen, if I am understanding this correctly. Should it be on launch? – DiscDev May 29 '13 at 23:30
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/30868/discussion-between-spotdog13-and-chris-wagner) – DiscDev May 29 '13 at 23:33
  • How did you go about this problem? We had this exact same scenario where new optional attributes seem to cause auto-migration failures. I appreciate any pointers. – John Estropia Aug 14 '13 at 02:55
  • 2
    Hey @erurainon. In this specific instance, the issue ended up being that I had accidentally modified an xcdatamodel file that was several versions old without knowing it. When I released a new version of the app, there were a handful of users that had not updated for a very long time, and therefore the "most recent" version of the xcdatamodel they had was the same as the file that I accidentally changed. When migration tried to happen on their devices it choked because the version of the data model file that it wanted to base migration on had been modified. Does that make sense? – DiscDev Aug 14 '13 at 14:42
  • That does make sense. But in our case we have unit tests to prevent this specific case so we are probably hitting some other problem. Thanks for the feedback! – John Estropia Aug 15 '13 at 03:19

0 Answers0