[vahan3x]

Local Swift packages get a dual representation in generated projects: the XCLocalSwiftPackageReference shown under Package Dependencies (desirable) and a redundant folder PBXFileReference in a group, Packages by default (often not). options.localPackagesGroup: "" only relocates that folder to the project root; it cannot remove it (see #1209).

This adds options.createLocalPackageGroups (default true). When set to false, XcodeGen still emits the package reference so Package Dependencies is populated, but skips the folder reference/group for all local packages — matching what Xcode produces via "Add Package Dependencies… → Add Local".

Default true = current output preserved byte-for-byte (no fixture changes needed)
New tests: spec parsing (default + explicit false + encode/decode round-trip) and generator behavior (no Packages group / folder refs, package references intact)
Docs (ProjectSpec.md) and CHANGELOG.md updated

[yonaskolb]

Thanks @vahan3x.

With the default (true) the generated output is unchanged, and with false local packages still resolve and build. A few problems show up when the option is false:

1. Package test targets in schemes can't run (blocking)

A scheme that tests a local package's test target, for example:

schemes:
  App:
    test:
      targets:
        - package: LocalPackage/LocalPackageTests

generates without errors, but xcodebuild test fails with There are no test bundles available to test. The same project with the option set to true runs the tests. Xcode only exposes a local package's test targets when the package is in the project as a folder reference; an XCLocalSwiftPackageReference on its own is treated as a dependency.

Suggested approach: when createLocalPackageGroups is false, still create the folder reference for any local package that a scheme references as a package: test target, document that, and add a test for the combination. A validation error for that combination would also work.

2. Project directory different from the spec directory

XCLocalSwiftPackageReference(relativePath:) and the scheme container: path are written relative to the spec directory rather than the project directory. Currently the folder reference, which is resolved relative to the project directory, hides this. With false it's the only reference left, so generating with --project out gives Could not resolve package dependencies in Xcode. This is an existing issue on master rather than something introduced here, so it doesn't need fixing in this PR, but a note in the docs would help in the meantime.

3. Docs

• localPackagesGroup and a local package's group have no effect when the option is false; the localPackagesGroup docs should mention that.
• XCLocalSwiftPackageReference is an Xcode 15 addition. With projectFormat: xcode14_0, Xcode 14 finds local packages through the folder reference, so false likely won't work there. A "requires Xcode 15 or later" note would cover it.
• The local packages section in Docs/Usage.md could point to the new option.

4. Naming (optional)

What gets removed is a folder reference rather than a group (with localPackagesGroup: "" there's no group involved at all), so a name like localPackageFolderReferences may be clearer. A per-package setting on Local Package that falls back to the global option would also let projects keep the folder only for packages whose tests run in schemes.