PBXProjEncoder crashes when sorting projectReferences if ProjectRef file element has nil name

[Ant-tree]

Summary

PBXProjEncoder crashes with Fatal error: Unexpectedly found nil while unwrapping an Optional value when encoding a project that containsPBXProject.projectReferences entries whose ProjectRef resolves to a PBXFileElement with name == nil.
This is common/valid in Xcode projects where PBXFileReference relies on path instead of name.

Steps to Reproduce

Create or open an .xcodeproj that includes a project reference (e.g., via Add Files to “…” → select another .xcodeproj).

Ensure the referenced PBXFileReference does NOT have a name field (only path), which is a typical pbxproj output.

Encode/write the project using XcodeProj with PBXOutputSettings.projReferenceFormat == .xcode (or any codepath that triggers sortProjectReferences).

Expected Behavior

Encoding should succeed. Sorting project references should use a stable display key even when name is nil (e.g., fallback to path).

Actual Behavior

Crash due to forced unwrap in PBXProjEncoder.sortProjectReferences:

• let lName = lFile.name!

Stack Trace / Error

XcodeProj/PBXProjEncoder.swift:491: Fatal error: Unexpectedly found nil while unwrapping an Optional value

Root Cause

PBXFileElement.name is optional and may be nil for project references. The encoder assumes it is always non-nil and force-unwraps it during sorting.

Proposed Fix

Use a safe fallback when name is nil. For example:

displayName = name ?? path ?? ""

And compare displayName case-insensitively.

I have a PR ready that implements this fallback and prevents the crash.

Additional Notes

This occurs with valid pbxproj files produced by Xcode, since PBXFileReference often omits name and uses path as the display label.

[dosubot]

Hi @Ant-tree! I'm Dosu and I’m helping the XcodeProj team.

You are correct about both the cause and the fix. The crash happens because PBXProjEncoder.sortProjectReferences force-unwraps the name property of PBXFileElement when sorting project references, but name is optional and can be nil for valid Xcode projects that rely on path instead of name. This is confirmed in the code, where both sides of the comparison use lFile.name! and rFile.name! without a fallback, leading to a runtime crash if name is nil see source.

PBXFileElement and PBXFileReference both define name as an optional property, and other parts of the codebase (like fileName() and plistKeyAndValue) already use name ?? path as a display fallback, matching Xcode’s behavior see source.

There are no existing issues, PRs, or documentation addressing this crash or its fix. Using name ?? path ?? "" as the display key for sorting is consistent with the rest of the codebase and Xcode’s own output, and should be safe. This change will make sorting deterministic and prevent the crash for all valid project references, including those without a name.

No side effects are expected as long as the fallback (name, then path, then empty string) is used consistently and compared case-insensitively, as you proposed. This matches both Xcode’s display logic and the intent of the original sorting.

Your PR approach is sound and aligns with best practices for handling this case.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}