OS
iOS
Description
Every added, moved, or renamed file currently rewrites project.pbxproj — a giant plist that git can't merge meaningfully, and that neither humans nor coding agents resolve reliably. #1827 is a recent case study: a working feature spent six weeks in conflict-resolution limbo (a Copilot clone in #1863, conflict-resolution attempts, finally a maintainer hand re-port — which still required hand-writing pbxproj entries to register two new files).
The project has already started down the fix: images and PreferenceKeys are Xcode 16 synchronized folders, and the project file is already in the Xcode 16 format (objectVersion = 70). Two options, which compose rather than compete:
Option A — convert the remaining source folders to buildable folders (right-click a group → "Convert to Folder"). Zero new tooling, no workflow change for anyone; adding/moving/deleting files stops touching the pbxproj entirely, and per-file target exceptions remain possible.
Done in #2085. #2102, #2101.
Option B — adopt XcodeGen on top. Targets and build settings move to a small, PR-reviewable project.yml; XcodeGen supports syncedFolder sources, so it generates the same synchronized folders as A — meaning regeneration is only needed when targets/settings change, not when files are added. The generate step can hook into the existing git-hooks setup (scripts/lint/ pattern) and Xcode Cloud's ci_post_clone.sh — or the generated pbxproj can simply stay committed, so contributors and Xcode Cloud change nothing and merge conflicts become "regenerate instead of hand-merge."
A is a strict subset of B's end state, so starting with A costs nothing and doesn't preclude B later. I'd suggest A now; B if/when a reviewable project definition is wanted. Trade-off overview: Strategies to avoid merge conflicts in Xcode Projects.
Participation
Additional comments
No response
Code of Conduct
OS
iOS
Description
Every added, moved, or renamed file currently rewrites
project.pbxproj— a giant plist that git can't merge meaningfully, and that neither humans nor coding agents resolve reliably. #1827 is a recent case study: a working feature spent six weeks in conflict-resolution limbo (a Copilot clone in #1863, conflict-resolution attempts, finally a maintainer hand re-port — which still required hand-writing pbxproj entries to register two new files).The project has already started down the fix:
imagesandPreferenceKeysare Xcode 16 synchronized folders, and the project file is already in the Xcode 16 format (objectVersion = 70). Two options, which compose rather than compete:Option A — convert the remaining source folders to buildable folders (right-click a group → "Convert to Folder"). Zero new tooling, no workflow change for anyone; adding/moving/deleting files stops touching the pbxproj entirely, and per-file target exceptions remain possible.
Done in #2085. #2102, #2101.
Option B — adopt XcodeGen on top. Targets and build settings move to a small, PR-reviewable
project.yml; XcodeGen supportssyncedFoldersources, so it generates the same synchronized folders as A — meaning regeneration is only needed when targets/settings change, not when files are added. The generate step can hook into the existing git-hooks setup (scripts/lint/pattern) and Xcode Cloud'sci_post_clone.sh— or the generated pbxproj can simply stay committed, so contributors and Xcode Cloud change nothing and merge conflicts become "regenerate instead of hand-merge."A is a strict subset of B's end state, so starting with A costs nothing and doesn't preclude B later. I'd suggest A now; B if/when a reviewable project definition is wanted. Trade-off overview: Strategies to avoid merge conflicts in Xcode Projects.
Participation
Additional comments
No response
Code of Conduct