chore: Add xcodegen for Xcode Project generation#131
Conversation
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
Add test targets to all scheme definitions in project.yml so XcodeGen generates proper <Testables> sections. Fix entitlements and Info.plist properties that were being wiped during generation.
Update stale $(SRCROOT)/Sources/... paths to $(SRCROOT)/Targets/App/Sources/... to match the actual file locations after the directory restructuring.
| test: | ||
| config: Debug | ||
| testPlans: | ||
| - path: Targets/FlinkyCoreTests/Config/FlinkyCoreTests.xctestplan | ||
| defaultPlan: true | ||
| profile: | ||
| config: Release | ||
| analyze: | ||
| config: Debug | ||
| archive: | ||
| config: Release |
There was a problem hiding this comment.
Bug: Hardcoded target identifiers in .xctestplan files are stale and do not match the newly generated project, which can cause test execution failures.
Severity: MEDIUM
Suggested Fix
The hardcoded identifiers in the .xctestplan files need to be updated to match the new identifiers in the project generated by XcodeGen. This typically requires opening the project in Xcode after generation and re-saving the test plans, which updates the identifiers to the correct values. The updated .xctestplan files should then be committed.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: project.yml#L469-L485
Potential issue: The `.xctestplan` files contain hardcoded target identifiers (UUIDs)
that become stale when the Xcode project is regenerated by XcodeGen, as regeneration
assigns new identifiers. This creates a mismatch between the test plan and the actual
project file. While Xcode might have a fallback mechanism to resolve test targets by
name, relying on this is fragile. This misconfiguration could lead to test execution
failures, particularly in CI environments or on different developer machines where the
fallback behavior may not be consistent, preventing tests from running.
Configure askForAppToLaunch, launchAutomaticallySubstyle, debugEnabled, and executable for proper app extension debugging workflow.
| <MacroExpansion> | ||
| <BuildableReference | ||
| BuildableIdentifier = "primary" | ||
| BlueprintIdentifier = "D4D359D82E1BDF540006226D" | ||
| BuildableName = "Flinky.app" | ||
| BlueprintName = "Flinky" | ||
| BlueprintIdentifier = "DC44702A3CEA6A63C027A551" | ||
| BuildableName = "ShareExtensionUITests.xctest" | ||
| BlueprintName = "ShareExtensionUITests" | ||
| ReferencedContainer = "container:Flinky.xcodeproj"> | ||
| </BuildableReference> | ||
| </BuildableProductRunnable> | ||
| </MacroExpansion> | ||
| <CommandLineArguments> | ||
| </CommandLineArguments> |
There was a problem hiding this comment.
Bug: The UITests and ShareExtensionUITests schemes in project.yml are missing the executable property, causing the generated LaunchAction to be misconfigured and preventing the "Run" action in Xcode.
Severity: MEDIUM
Suggested Fix
In project.yml, add an explicit run: section with executable: Flinky to both the UITests and ShareExtensionUITests scheme definitions. This will ensure XcodeGen correctly configures the LaunchAction to point to the host application.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location:
Flinky.xcodeproj/xcshareddata/xcschemes/ShareExtensionUITests.xcscheme#L103-L116
Potential issue: The `project.yml` definitions for the `UITests` and
`ShareExtensionUITests` schemes are missing a `run:` section with an `executable:`
property. This causes XcodeGen to generate `.xcscheme` files where the `LaunchAction`
incorrectly points to the test bundle itself (e.g., `UITests.xctest`) instead of the
host application (`Flinky.app`). As a result, developers using the "Run" action (⌘R) in
Xcode with these schemes selected will encounter a failure, as a test bundle cannot be
launched as an executable application. This breaks a common local development and
testing workflow.
Also affects:
Flinky.xcodeproj/xcshareddata/xcschemes/UITests.xcscheme:70~84
… groups - Remove XcodeGen `info` sections; move custom properties to INFOPLIST_KEY_* build settings (matches original main pattern) - Restore minimal Info.plist files (empty for App, NSExtension-only for ShareExtension) - Split each target's sources into explicit subdirectories: - Sources: synced folder (auto-discovery, target membership) - Config: regular group with buildPhase: none (navigator only) - Generated: regular group with buildPhase: none (navigator only) - Prevents .gitkeep, generated-en.strings, and xctestplan files from leaking into app/test bundles
| targets: | ||
| FlinkyCoreTests: [test] | ||
| test: | ||
| config: Debug |
There was a problem hiding this comment.
Bug: The FlinkyCoreTests, Tests, and ShareExtensionTests schemes are missing the Flinky application as a build target, which will cause hosted unit tests to fail when run individually.
Severity: MEDIUM
Suggested Fix
Update project.yml to include the Flinky target in the build section for the FlinkyCoreTests, Tests, and ShareExtensionTests schemes. This ensures Xcode builds the host application before attempting to run the tests that depend on it.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: project.yml#L537-L540
Potential issue: The unit test schemes `FlinkyCoreTests`, `Tests`, and
`ShareExtensionTests` are configured with a `TEST_HOST` setting that points to
`Flinky.app`. However, these schemes do not include the `Flinky` application target in
their build configurations. When running tests from these individual schemes, such as in
a CI environment, Xcode will not build the host application. This will cause the test
runner to fail at execution time with a "Could not find test host" error because the
required application binary will be missing.
Also affects:
project.yml:611~614project.yml:659~662
1 participant
No description provided.