On August 3 I picked up an open issue on getsentry/XcodeBuildMCP. A freshly scaffolded iOS project fails its first build with a missing package product, and the report prints the exact command that does it. I ran that command. The build succeeded and the app launched. If I had stopped there I would have written 'cannot reproduce' on a bug that was still fully present.
The report was filed against Xcode 26.4. I was on 26.6. Its diagnosis said the workspace lists the local Swift package only as a group FileRef, and that this does not make Xcode resolve it as a package. On 26.6 it did. The build log shows the package resolved off that FileRef, the feature target compiled, the app launched. Nothing about the generated project had improved. The workspace route had simply stopped needing the part that was broken.
| Entry point | Result on Xcode 26.6 | What it settles |
|---|---|---|
| build-and-run, workspace path (the filed command) | Build succeeded, app launched | That the workspace can resolve the package by itself. Nothing about the project. |
| build, project path | Missing package product 'SmokeTestFeature' | That the generated .xcodeproj is not self-contained. This is the filed defect. |
| Both, after adding the local package reference | Both succeeded, no duplicate-package regression | That the report's diagnosis was right the whole time. |
So the fix was the one the report already pointed at: give the project its own local package reference instead of leaning on the workspace to supply it. The part that nearly got lost was the reason to look at all. A reproduction that passes tells you that route is clear. It does not tell you the defect is gone, and from the terminal those two are the same result.