Support PBXFileSystemSynchronizedRootGroup merges

[ivoidcat]

Summary

• add handling for PBXFileSystemSynchronizedRootGroup in add_child_to_component
• support attaching synchronized root groups under PBXNativeTarget.file_system_synchronized_groups
• allow group handling paths to accept PBXFileSystemSynchronizedRootGroup where appropriate

Test plan

• Build and install patched gem locally
• Reproduce merge on a project containing fileSystemSynchronizedGroups
• Verify conflict resolution no longer fails with unsupported component errors

[Akshay Jain (1880akshay)]

Ben Yohay (@byohay) Barak Weiss (@barakwei) Yonathan Oren (@oryonatan) are we planning to merge this?

[Noam Freeman (noamfreeman)]

Thanks for picking this up!

can you share the pbxproj (or the diff) that motivated it? I want to
confirm whether the PBXFileSystemSynchronizedRootGroup is also referenced as a child of
mainGroup, because in the case I ran where it is, apply_group_additions drops it (it filters on
PBXGroup/PBXVariantGroup) and the folder ends up attached to the target but absent from the group
tree.

Relatedly, the PBXNativeTarget branch always calls project.new(...), whereas every other add path
here resolves the existing object (add_file_reference via hierarchy_path, add_reference_proxy
via find_reference_proxy) — if the group arrives from the group tree too, doesn't this end up with
two root groups for one folder? It's also missing the Settings.allow_duplicates guard the sibling
paths have.

Finally, could you add specs (every other supported isa has them), and drop the
respond_to?(:file_system_synchronized_groups) fallback plus the PBXGroup/sync-group no-op
branches — only PBXNativeTarget declares that has_many, and a sync root group has no children,
so none of those paths can fire.

[ivoidcat]

Thanks for picking this up!

can you share the pbxproj (or the diff) that motivated it? I want to confirm whether the PBXFileSystemSynchronizedRootGroup is also referenced as a child of mainGroup, because in the case I ran where it is, apply_group_additions drops it (it filters on PBXGroup/PBXVariantGroup) and the folder ends up attached to the target but absent from the group tree.

Relatedly, the PBXNativeTarget branch always calls project.new(...), whereas every other add path here resolves the existing object (add_file_reference via hierarchy_path, add_reference_proxy via find_reference_proxy) — if the group arrives from the group tree too, doesn't this end up with two root groups for one folder? It's also missing the Settings.allow_duplicates guard the sibling paths have.

Finally, could you add specs (every other supported isa has them), and drop the respond_to?(:file_system_synchronized_groups) fallback plus the PBXGroup/sync-group no-op branches — only PBXNativeTarget declares that has_many, and a sync root group has no children, so none of those paths can fire.

Thanks for the detailed review.

Unfortunately, quite a bit of time has passed and I no longer have the original .pbxproj or diff that reproduced the issue, so I cannot confirm the exact object graph from that project.

As far as I remember, the project had been created or modified with Xcode 16 and contained a PBXFileSystemSynchronizedRootGroup. When Kintsugi applied the merge diff, that object appeared under PBXNativeTarget.fileSystemSynchronizedGroups, but add_child_to_component did not handle its isa, so the merge failed with an unsupported component error.

This patch was a narrow fix for that failure. It added dispatching for PBXFileSystemSynchronizedRootGroup and created and attached the object to PBXNativeTarget#file_system_synchronized_groups. That was sufficient to make the affected project merge successfully.

Looking at the implementation again, I agree that it may be incomplete if the same synchronized root group is also referenced from mainGroup. In that case, apply_group_additions currently filters it out, while the PBXNativeTarget path creates a new object instead of resolving an existing one, which could result in a missing group-tree entry or duplicate objects. I also agree that the respond_to? fallback and the group no-op branches are unnecessary.

I no longer have the original fixture to verify whether the synchronized root group was present in both locations, so this should be treated as a project-specific workaround rather than a complete implementation. A proper fix should handle the group in the mainGroup addition flow, reuse the same project object when attaching it to the target, respect Settings.allow_duplicates, and include specs for both references.

[Noam Freeman (noamfreeman)]

fair. it was a long time. is your project still using anything but buildable folders? if so, i'l try to add a proper fix.

[Ryan Zulkoski (rzulkoski)]

Hi Noam Freeman (@noamfreeman) ivoidcat — jumping in from the sidelines. We hit this same failure on an Xcode 26 project that uses buildable folders (introduced in Xcode 16), and used ivoidcat's patch here plus Noam Freeman (@noamfreeman)'s review as the spec to build out a complete implementation (with Claude Code's help — the resulting commit is co-authored accordingly).

It follows the review checklist directly:

• PBXFileSystemSynchronizedRootGroup is now handled in the main-group addition/removal pipeline, so it's no longer dropped by apply_group_additions — the missing-from-the-group-tree case you flagged.
• The target attachment resolves and reuses the object created in the group tree instead of project.new, so one folder never yields two root groups — guarded by Settings.allow_duplicates.
• Dropped the respond_to? fallback and the no-op branches.
• Specs cover both references (main group + target), plus explicit file types/folders, exceptions, removal, and the duplicate guard, and there's an end-to-end integration spec that reproduces the original failure.

It also handles exceptions (target/build-phase membership), which needed a workaround for an xcodeproj bug where PBXFileSystemSynchronizedGroupBuildPhaseMembershipExceptionSet#display_name calls the nonexistent build_phase.name (still present in 1.28.1 and master). bundle exec rake is green on the pinned xcodeproj range.

Since you mentioned you might take a crack at a proper fix, I didn't want to step on that — would a PR be welcome, or are you already mid-fix? Happy to open one (crediting this thread) whenever suits.

[Noam Freeman (noamfreeman)]

hi Ryan Zulkoski (@rzulkoski)!
a PR would be welcome