1 Reply
      Latest reply on Jul 1, 2019 11:52 AM by iter9_dev
      iter9_dev Level 1 Level 1 (0 points)

        For the past several weeks I've been dealing with a maddening CoreData issue, which feels like an Xcode bug. (Currently on Xcode 10.2.1, running iOS 12.3.1 on my devices.)

         

        I have a large project using CoreData with several model versions, using lightweight migration. The latest is version 6, which adds an NSData attribute 'foo' to the managed object. The app creates and persistently stores and manages databases in this format.

         

        However, once in a while the app will build and launch and throw an exception saying that 'foo' is an unrecognized selector, and crash. (As if it were built using an older model version.) Worse, when this happens it corrupts the CoreData store, deleting all 'foo' attributes. To get the app to stop crashing, I've found that I can simply toggle the 'Current Model Version' in Xcode from 6 to 5 (without rebuilding) and back to 6, then rebuild and relaunch, and it works correctly, except that the previous 'foo' attributes stay deleted. Obviously, it would be very bad if a build affected by this bug were to be released on the App Store, since it would destroy a ton of user data.

         

        I am sort of at a loss for how to troubleshoot/fix this. I'd like to be able to check for this condition at startup before the database is loaded, but CoreData classes don't work with 'instancesRespondToSelector' (because the selectors are created dynamically). If I wait until the model is loaded before checking (e.g. by triggering the exception and catching it), it will corrupt the database. And it seems pretty heavy-handed to create a dummy database each time I launch, just in order to check for this bug.

         

        Any help is welcome. This is the first time in years that I've considered opening a Technical Support Incident!

         

        Thanks,

        Ben