XCode reverts CoreData's .xccurrentversion

I am experiencing an issue where XCode reverts .xccurrentversion file in my iOS app to the first version whenever xcodebuild is run or whenever XCode is started. This means I can build the app and run tests in XCode if I discard the reversion .xccurrentversion on XCode start. However, testing on CI is impossible because the version the tests rely on are reverted whenever xcodebuild is run.

The commands I run to reproduce the issue

❯ git status
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   Path/.xccurrentversion

no changes added to commit (use "git add" and/or "git commit -a")
❯ git checkout "Path/.xccurrentversion"
Updated 1 path from the index
❯ git status
nothing to commit, working tree clean
❯ xcodebuild \
            -scheme Scheme \
            -configuration Configuration \
            -sdk iphonesimulator \
            -destination 'platform=iOS Simulator,name=iPhone 16 Pro,OS=latest' \
            -skipPackagePluginValidation \
            -skipMacroValidation \
            test > /dev/null  # test fails because model version is reverted
❯ git status
HEAD detached at pull/249/merge
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   Path/.xccurrentversion

no changes added to commit (use "git add" and/or "git commit -a")

I have experienced such issue in 16.3 (16E140) and 16.2 (16C5032a).

Similar issues/solutions I have found online are the following. But they are either not relevant or do not work in my case.

Is anyone aware of any solution? Is there a recommended way I can run diagnostics on XCode and file a feedback?

I've tried with creating a versioned Core Data model with Xcode 16.2 (16C5032a), and don't see that the .xccurrentversion file is changed when I switch model version and build the project.

I am wondering if your Core Data model (the .xcdatamodeld bundle package) has something special. If you can provide a minimal project with steps to reproduce the issue, maybe I can take another look. Your post can contain a link to where your test project is hosted.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Hi Ziqiao,

Thanks for help me out. I tried to create a new project and indeed there is no issue. I tried to move my model that has the issue to the new project and the issue persist. So your speculation of my .xcdatamodeld being weird is correct. You can find my project that reproduces the issue here: https://drive.google.com/file/d/1nHYsl9JANR9YI4jpXA98wDWp28BGQh50/view?usp=sharing.

Before opening the project, you can see that coredataissue/Model.xcdatamodeld/.xccurrentversion is GroupMetaData.xcdatamodel, but after opening the xcode project, the coredataissue/Model.xcdatamodeld/.xccurrentversion becomes Model.xcdatamodel.

Thanks for sharing your project. I haven't had a chance to look into your Model.xcdatamodeld, but a quick glance at a model version content, coredataissue/coredataissue/Model.xcdatamodeld/Group.xcdatamodel/contents, for example, sees the following key, which doesn't appear in a Core Data model that is created with current public release Xcode and doesn't have the issue:

usedWithSwiftData="YES" 

So I am curious how you created the Core Data model. If you create the same model with the latest Xcode, will that demonstrate the same issue?

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

That's interesting. I created this model in Version 16.3 (16E140), which I believe is the current stable XCode release.

I created new models using Editor > Add Model Version....

I just tested creating another model, and the new one still contains usedWithSwiftData="YES". I don't need my models to be SwiftData compatible at this moment. So, do you think removing this field would resolve the issue?

I have the same problem, xcodebuild permanently set the old model, even if I explicitly change that manually in .xccurrentVersion and start the build.

I have solved it temporarily by revoking the write permissions to the directory CoreData.xcdatamodeld (chmod -w ).

[@Daniel Scheibe](https://developer.apple.com/forums/profile/Daniel Scheibe) Thanks for sharing your solution. This workaround doesn't seem quite convenient because we need to revert the permission back when creating a new model version. :((

Also, if you could provide more information, when did you first find out this issue and how long it's been around for you?

@LZBLT Unfortunately, I can't say exactly how long we've had this error. But even in a new test project there is the same behavior.

@LZBLT But it seems to work if I write the version number at the beginning of the model. Xcode seems to simply take the last sorted file from the package / directory. but I don't know what effect this has on the live app and the existing database. We actually have a version number but I don't know if the name of the model is used.

Old Name was eg: BaseDataBaseV1 AddedNewEntityV2 NewEntityAdditionV3

now: V1BaseDataBase V2AddedNewEntity V3NewEntityAddition

I also don't think that the file is ever read for configuration and is simply overwritten directly when the project is open and then works with the new (wrong) values.

if you set an own identifier there should be no problem with the hash from the old model if you rename the model files.

@DTS Engineer Hi Ziqiao, could you provide more insights and updates if you have any? Thanks!

I did some of investigation of this issue because I ran into the same problem when trying to convert an old project from groups to folders.

I discovered what is happening is that Xcode 16 changes the model's current version to the last one alphabetically.


I was able to reproduce it this way:

  1. Create a brand new, folder-based, Xcode project.
  2. Add an xcdatamodeld with one entity.
  3. Add a new model version and name it "a".
  4. Make it current.
  5. Quit Xcode.
  6. Relaunch Xcode.

Expected result: The "a" model version should still be current.

Actual result: The original model version is current.

I was able to reproduce with Xcode 16.2 and 16.4. It appears to be fixed in Xcode 26 beta 6.


Based on these steps, one workaround appears to be to name the model versions alphabetically.

Another workaround is to keep the xcdatamodeld file in a group, not a folder.

And of course if you can switch to Xcode 26, then you don't need to workarounds above.

I had been too swamped to be able to continue this conversation because of the highly prioritized work related to WWDC25, and after that I lost the track of this thread. Sorry for that. Thanks to another developer reaching out via DTS with the same issue, I am now picking up this thread, which hopefully is not too late.

I'd like to confirm that I can now reproduce the issue. As folks have mentioned, the issue happens only in an Xcode project using folders, not groups. I've always used groups which helps me better organize files logically, and so had not seen the issue before.

Xcode 26 Beta 6 doesn't fix the issue.

Before the issue is fixed from the system side, the workarounds folks mentioned, like using groups instead or giving the new model version a name alphabetically ordered to the last, sound good to me.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

XCode reverts CoreData's .xccurrentversion
 
 
Q