Open Radar

 
Summary:
Core Data model fields can fail to save value changes, requiring multiple attempts.

Steps to Reproduce:
1. Start a single view iOS app with Core Data.
2. Add an entity called “Photo” (or whatever) with a “foo” attribute.
3. Generate the NSManagedObject subclasses.
4. Go back to the xcdatamodel file (the model editor).
5. Select the entity.
6. Show the Data Model Inspector
7. Change the “CodeGen” property to manual/none
8. *do not hit cmd-s, or otherwise save the file
9. Try to build -> get an error that 2 files with same name are generated)
10. Clean, clean derived folder, try to build again. -> same error
11. Go back to the .xcdatamodel file. Look at the entity -> class - CodeGen setting.

Expected Results:
Xcode should keep the setting when a user changes it. It should *also* show the setting as it actually is, that is the one that will be used. These *should* be the same thing, but even if the first one fails, the second one *should not fail*! 

Actual Results:
First, the setting will often change in the UI, but not be applied at compile time. Hence the errors.
Secondly, and more frustratingly, sometimes the user will go to different files and back, will select different fields and back, and *STILL* the UI will show “manual/none” even though compiling proves that a different setting is being used. The user must save the file changes, AND may also need to clean derived data, in order to clear the error. Because the UI is inconsistent though, there’s no way to know this. Even worse, sometimes these steps plus saving the file have to all be done multiple times before the change “sticks” and the app can compile correctly again. 

Regression:
I am seeing this more in the Core Data editor this week than I have before. But I don’t know if it’s a regression in Xcode, or if we’re just exercising Xcode enough to trigger it more often.

Notes:
This same sort of bug happens throughout Xcode’s visual editors. Interface Builder is notorious for it. It has been happening there for a long time and really turns people off the editor. I teach classes throughout the world, and this is one big pain point for people relatively new to Xcode. It is one thing to make mistakes yourself, but having Xcode sabotage your changes is the worst kind of frustrating. I have to teach people my bad habits like *always* selecting a different field after editing a field or dropdown list, hitting cmd-s constantly in Xcode (arguably a good habit but only because software sucks), and worst, cleaning DerivedData and restarting Xcode when trying the change repeatedly doesn’t work otherwise.