If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/RobertGummesson/BuildTimeAnalyzer-for-Xcode shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 2mo ago
• 14 active contributors
• MIT licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 64% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live RobertGummesson/BuildTimeAnalyzer-for-Xcode repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/RobertGummesson/BuildTimeAnalyzer-for-Xcode.

What it runs against: a local clone of RobertGummesson/BuildTimeAnalyzer-for-Xcode — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in RobertGummesson/BuildTimeAnalyzer-for-Xcode | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 92 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of RobertGummesson/BuildTimeAnalyzer-for-Xcode. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode.git
#   cd BuildTimeAnalyzer-for-Xcode
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of RobertGummesson/BuildTimeAnalyzer-for-Xcode and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "RobertGummesson/BuildTimeAnalyzer-for-Xcode(\\.git)?\\b" \\
  && ok "origin remote is RobertGummesson/BuildTimeAnalyzer-for-Xcode" \\
  || miss "origin remote is not RobertGummesson/BuildTimeAnalyzer-for-Xcode (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "BuildTimeAnalyzer/ViewController.swift" \\
  && ok "BuildTimeAnalyzer/ViewController.swift" \\
  || miss "missing critical file: BuildTimeAnalyzer/ViewController.swift"
test -f "BuildTimeAnalyzer/LogProcessor.swift" \\
  && ok "BuildTimeAnalyzer/LogProcessor.swift" \\
  || miss "missing critical file: BuildTimeAnalyzer/LogProcessor.swift"
test -f "BuildTimeAnalyzer/BuildManager.swift" \\
  && ok "BuildTimeAnalyzer/BuildManager.swift" \\
  || miss "missing critical file: BuildTimeAnalyzer/BuildManager.swift"
test -f "BuildTimeAnalyzer/CompileMeasure.swift" \\
  && ok "BuildTimeAnalyzer/CompileMeasure.swift" \\
  || miss "missing critical file: BuildTimeAnalyzer/CompileMeasure.swift"
test -f "BuildTimeAnalyzer/DerivedDataManager.swift" \\
  && ok "BuildTimeAnalyzer/DerivedDataManager.swift" \\
  || miss "missing critical file: BuildTimeAnalyzer/DerivedDataManager.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 92 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~62d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/RobertGummesson/BuildTimeAnalyzer-for-Xcode"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

BuildTimeAnalyzer is a native macOS application that parses Xcode's build logs and presents a detailed breakdown of Swift compilation times by file and function. It helps iOS/macOS developers identify slow-to-compile Swift code by reading derived data logs and visualizing compilation metrics in a searchable table UI. Single-target macOS app: BuildTimeAnalyzer/ contains the main logic split into specialized modules—LogProcessor.swift handles Xcode log parsing, DerivedDataManager.swift accesses build artifacts, CompileMeasure.swift models compile metrics, and ViewController.swift + ViewControllerDataSource.swift drive the NSTableView UI. CSVExporter.swift and XcodeDatabase.swift provide data export. Tests live in BuildTimeAnalyzerTests/.

iOS and macOS developers optimizing build performance in large Swift projects. They use this tool to identify bottleneck source files causing excessive build times, then refactor or restructure those files to reduce incremental build overhead.

Moderately mature but inactive: the repo shows 53KB of Swift code with a basic test suite (CompileMeasureTests.swift, ViewControllerDataSourceTest.swift) and CI via .travis.yml, suggesting it was production-ready circa 2016–2020. However, no recent activity is visible in the file list; the LICENSE header says 2016–2026 but the repository appears dormant relative to modern Swift/Xcode versions.

Single-maintainer project (RobertGummesson) with no visible dependency management file (no Package.swift or Podfile), making it unclear how external dependencies are managed. The app directly integrates with Xcode's derived data formats and build logs (via DerivedDataManager.swift, LogProcessor.swift), so it is fragile to Xcode version changes. Last commit date is not visible, but the lack of Swift 5+ idioms in the codebase suggests it may not be updated for recent Xcode releases.

No active development is evident from the file list. The project appears stable but unmaintained; no open PRs, milestones, or recent commits are visible.

1. Clone the repo: git clone https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode.git. 2. Open in Xcode: open BuildTimeAnalyzer.xcodeproj. 3. Build and run: press Cmd+R or select Product > Run. No additional package manager steps are required (no CocoaPods, SPM, or Carthage setup).

Daily commands: Open BuildTimeAnalyzer.xcodeproj in Xcode and press Cmd+R, or build via xcodebuild -scheme BuildTimeAnalyzer. The app launches as a macOS GUI; it does not have a CLI mode.

• BuildTimeAnalyzer/ViewController.swift — Main UI controller that orchestrates the entire build time analysis workflow and user interactions.
• BuildTimeAnalyzer/LogProcessor.swift — Core engine that parses Xcode build logs and extracts compile time measurements for individual Swift files.
• BuildTimeAnalyzer/BuildManager.swift — Coordinates build execution, log capture, and triggering the analysis pipeline.
• BuildTimeAnalyzer/CompileMeasure.swift — Data model representing individual file compilation measurements; used throughout the app for analysis and export.
• BuildTimeAnalyzer/DerivedDataManager.swift — Manages access to Xcode's derived data directory where build logs are located.
• BuildTimeAnalyzer/ViewControllerDataSource.swift — Provides table data binding and filtering logic between parsed compile measures and the UI.
• BuildTimeAnalyzer/CSVExporter.swift — Exports analyzed build metrics to CSV format for external reporting and analysis.

• LogProcessor (Swift regex, string parsing) — Parses Xcode build log output and extracts individual Swift file compilation durations using regex or string matching
  • Failure mode: If log format changes in future Xcode versions, parsing will fail silently or produce incorrect measurements
• BuildManager (Process/Task execution, FileManager) — Orchestrates the build lifecycle: executes xcodebuild, waits for completion, signals log availability
  • Failure mode: If xcodebuild path changes or project structure is invalid, build will fail and no logs will be available
• DerivedDataManager (FileManager, URL paths, macOS file system conventions) — Locates Xcode's derived data directory and identifies build logs for the target project
  • Failure mode: If user moves or symlinks derived data, manager may not find logs; if Xcode changes storage location, tool breaks
• ViewControllerDataSource — Mediates between parsed CompileMeasure array and NSTableView; implements filtering, sorting, and row binding

Add a new build metric to the analysis

1. Add a new property to the CompileMeasure struct to store your metric (BuildTimeAnalyzer/CompileMeasure.swift)
2. Update LogProcessor.swift to extract and parse your metric from the build log (BuildTimeAnalyzer/LogProcessor.swift)
3. Add a new table column in the storyboard and bind it in ViewControllerDataSource (BuildTimeAnalyzer/Main.storyboard)
4. Update CSVExporter.swift to include the new metric in exports (BuildTimeAnalyzer/CSVExporter.swift)

Add a new UI control or filter option

1. Add the UI element (button, checkbox, dropdown) to the storyboard (BuildTimeAnalyzer/Main.storyboard)
2. Add an IBAction in ViewController to handle user interaction (BuildTimeAnalyzer/ViewController.swift)
3. Implement the filter/sort logic in ViewControllerDataSource (BuildTimeAnalyzer/ViewControllerDataSource.swift)
4. Persist the preference in UserSettings if it should survive app restarts (BuildTimeAnalyzer/UserSettings.swift)

Support a new Xcode project structure or log format

1. Update DerivedDataManager to handle the new project layout (BuildTimeAnalyzer/DerivedDataManager.swift)
2. Modify LogProcessor parsing logic to handle the new log format (BuildTimeAnalyzer/LogProcessor.swift)
3. Add unit tests to validate parsing on the new format (BuildTimeAnalyzerTests/CompileMeasureTests.swift)

• Swift 5 — The tool analyzes Swift build times, so using Swift for the tool itself demonstrates its own compilation profiles and maintains consistency
• macOS/Cocoa (AppKit) — Xcode is macOS-only, and direct access to Xcode's derived data and project metadata requires native macOS APIs
• Xcode project file integration — Must parse and interact with .xcodeproj structures and invoke xcodebuild to trigger instrumented builds
• CSV export — Enables bulk data analysis in spreadsheets and external tools without requiring proprietary formats

• Trigger full clean builds to capture accurate per-file compile times

  • Why: Incremental builds hide the true individual file compilation cost; clean builds are necessary for accurate analysis
  • Consequence: Slow feedback loop for developers—each analysis takes minutes, but trade-off is necessary for data accuracy

• Parse Xcode build logs as primary data source rather than instrumenting the Swift compiler directly

  • Why: No need to modify Xcode or Swift compiler; works with standard Xcode installations
  • Consequence: Dependent on Xcode log format stability; log format changes break parsing logic

• macOS-only application

  • Why: Xcode and derived data are macOS-exclusive; tight integration requires native platform access
  • Consequence: No Linux or Windows support; limits audience to macOS developers

• Real-time continuous monitoring of builds (tool requires explicit project selection and manual analysis trigger)
• Integration with CI/CD pipelines (designed as a standalone macOS developer tool)
• Analysis of Objective-C or other non-Swift languages
• Optimization recommendations or automatic code refactoring
• Support for older Xcode versions or Swift versions before 5

1. Xcode version fragility: LogProcessor.swift's regex patterns depend on Xcode's build log format, which has changed across versions (Swift 4 vs. 5 vs. 6); older logs may not parse correctly. 2. Derived data path assumptions: DerivedDataManager.swift assumes a standard ~/Library/Developer/Xcode/DerivedData structure; non-standard Xcode configurations may break discovery. 3. No error recovery: if a log file is malformed, LogProcessor may silently skip entries rather than fail gracefully. 4. Direct file system access: the app reads Xcode's internal databases directly; no public API is used, so changes to Xcode internals break functionality. 5. Bridging header required: any pure Swift changes must not use Objective-C-only APIs; the Bridging-Header.h is minimal and may need extension for new interop.

• Xcode Derived Data — This app reads build artifacts and logs directly from ~/Library/Developer/Xcode/DerivedData; understanding its structure (build logs, intermediate files, indexing data) is essential to using and modifying DerivedDataManager.swift and LogProcessor.swift
• Regular Expression Parsing — LogProcessor.swift uses regex to extract compile times and file names from Xcode's unstructured text logs; proficiency with Swift's NSRegularExpression or regex literals is required to adapt parsing to new Xcode versions
• NSTableViewDataSource & Delegate — ViewControllerDataSource.swift implements NSTableViewDataSource to display parsed compile metrics in the UI; understanding AppKit's table model is crucial for any UI changes or sorting/filtering enhancements
• Incremental Compilation — The entire purpose of this tool is to identify bottlenecks in Swift's incremental compilation; understanding how the Swift compiler tracks dependencies and recompiles only affected files is necessary to interpret the metrics correctly
• Swift Type-Checking Performance — Slow Swift compilation is often due to expensive type-checking (template expansion, constraint solving); BuildTimeAnalyzer identifies which files/functions cause this, making knowledge of Swift type system complexity relevant to using the tool
• macOS App Lifecycle & Cocoa Events — ViewController.swift and AppDelegate.swift manage the app's lifecycle and file selection dialogs; familiarity with AppKit event handling and NSOpenPanel is needed for UI modifications

• Realm/SwiftLint — Another macOS developer tool for Swift that parses source code; relevant for understanding how to integrate with Xcode workflows and handle file I/O at scale
• apple/swift-evolution — Official Swift evolution repository; useful for understanding Swift compilation changes across versions that may affect log parsing in BuildTimeAnalyzer
• fastlane/fastlane — iOS/macOS build automation framework that also parses Xcode logs and derived data; shares similar integration challenges and parsing patterns
• yonaskolb/XcodeGen — Generates Xcode projects from specs; complementary to BuildTimeAnalyzer for developers optimizing build configurations and analyzing their impact on compile times
• kishikawakatsumi/XCLogParser — Another Xcode build log parser written in Swift (more recent); direct alternative that may inform improvements to BuildTimeAnalyzer's parsing logic

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for LogProcessor.swift and BuildManager.swift

The repo has minimal test coverage (only CompileMeasureTests.swift and ViewControllerDataSourceTest.swift exist). LogProcessor.swift and BuildManager.swift are critical components for parsing build logs and managing builds, but have no test coverage. Adding tests here would catch regressions early and make refactoring safer.

• [ ] Create BuildTimeAnalyzerTests/LogProcessorTests.swift with tests for log parsing edge cases (malformed logs, missing timestamps, various Xcode versions)
• [ ] Create BuildTimeAnalyzerTests/BuildManagerTests.swift with tests for build state transitions and error handling
• [ ] Add mock objects for DerivedDataManager.swift dependencies to isolate LogProcessor and BuildManager logic
• [ ] Run tests via .travis.yml to verify they integrate with existing CI

Add GitHub Actions workflow to replace/supplement Travis CI

The repo uses .travis.yml for CI, but GitHub Actions is now the modern standard for GitHub repos and provides better integration. The .travis.yml file exists but the repo should have a .github/workflows/build.yml to build and test on macOS with Swift 5 as documented in the README.

• [ ] Create .github/workflows/build.yml with macOS runner and Xcode setup
• [ ] Add steps to build BuildTimeAnalyzer.xcodeproj using xcodebuild
• [ ] Add step to run XCTest suite (BuildTimeAnalyzerTests)
• [ ] Include Swift version matrix testing (minimum supported to latest) per the Swift 5 badge in README

Extract and document the CSV export functionality (CSVExporter.swift) with integration tests

CSVExporter.swift exists but has no visible unit tests. This is user-facing functionality that should be well-tested and documented. Adding tests ensures the CSV output format remains stable across refactors and validates the export feature works correctly with the CompileMeasure data model.

• [ ] Create BuildTimeAnalyzerTests/CSVExporterTests.swift with tests for: valid CSV output format, handling special characters in file names, empty measure arrays, and large datasets
• [ ] Add a test fixture of sample CompileMeasure objects in BuildTimeAnalyzerTests/Fixtures/ for reuse across tests
• [ ] Add documentation comments to CSVExporter.swift explaining the CSV schema (expected columns, data types)
• [ ] Verify tests run alongside existing test suite

• idea: Add unit tests for LogProcessor.swift parsing edge cases—currently only CompileMeasureTests.swift and ViewControllerDataSourceTest.swift exist. Tests for malformed logs, missing timestamps, and Swift 5+ vs. 6 log format differences would improve robustness.
• idea: Extend CSVExporter.swift to support additional formats (JSON, TSV, or HTML table) and add tests. The current CSV-only approach limits analysis flexibility.
• idea: Document the expected Xcode build log format in a README or inline comments in LogProcessor.swift, including regex pattern explanations. New contributors cannot easily understand how to adapt to Xcode version changes without this.

This macOS application for analyzing Xcode build times shows a moderate security posture. The primary concerns are around file system operations on user directories (potential symlink/path traversal risks), log parsing without evident input validation, and CSV export functionality that may not properly escape data. The application appears to be a relatively simple utility without external dependencies (based on visible file structure), which reduces supply chain risks. However, the interaction with system file paths and processing of potentially untrusted log data warrants careful review and hardening of input validation routines. Code quality appears reasonable with no obvious hardcoded secrets or injection vulnerabilities visible in the file structure.

• Medium · Potential Insecure File System Operations — BuildTimeAnalyzer/DirectoryMonitor.swift, BuildTimeAnalyzer/DerivedDataManager.swift. The codebase includes DirectoryMonitor.swift and DerivedDataManager.swift which likely perform file system operations on Xcode derived data. Without proper validation of file paths and symbolic link handling, this could be vulnerable to directory traversal or symlink attacks. Fix: Implement strict path validation, resolve symbolic links using realpath equivalents, and validate that accessed files are within expected directories. Use URL(fileURLWithPath:) safely with proper canonicalization.
• Medium · Log File Processing Without Input Validation — BuildTimeAnalyzer/LogProcessor.swift. LogProcessor.swift processes build logs from Xcode. Parsing untrusted log data without strict validation could lead to parsing errors, denial of service, or if logs are later displayed in UI without escaping, potential XSS-like vulnerabilities. Fix: Implement strict parsing rules, validate log format before processing, use safe string parsing methods, and sanitize any log content before displaying in the UI.
• Medium · CSV Export Functionality May Not Escape Data — BuildTimeAnalyzer/CSVExporter.swift. CSVExporter.swift exports build data to CSV format. If the export doesn't properly escape special characters, quotes, or newlines, it could create malformed CSV files or enable CSV injection attacks when opened in spreadsheet applications. Fix: Properly escape all CSV fields according to RFC 4180 standard. Wrap fields containing commas, quotes, or newlines in double quotes and escape internal quotes by doubling them.
• Low · Missing Code Signing Validation — BuildTimeAnalyzer/BuildManager.swift, BuildTimeAnalyzer/XcodeDatabase.swift. The application interacts with Xcode and processes build outputs. There's no visible verification of Xcode's code signature or validation that the tool is operating on legitimate Xcode installations. Fix: Consider validating the code signature of Xcode installations before processing their data. Verify that accessed files belong to legitimate Xcode installations.
• Low · Bridging Header Without OBJC Safety — BuildTimeAnalyzer/BuildTimeAnalyzer-Bridging-Header.h. The presence of BuildTimeAnalyzer-Bridging-Header.h suggests Objective-C interop. C imports through bridging headers could introduce memory safety issues if not carefully managed. Fix: Audit all Objective-C and C APIs exposed through the bridging header. Use safe Swift wrappers where possible. Consider migrating to pure Swift alternatives.
• Low · No Visible Dependency Lock File — Repository root. No Package.swift, Podfile, Cartfile, or similar dependency management file is visible in the provided structure. This makes it difficult to audit dependencies for known vulnerabilities. Fix: If using any external dependencies, implement a dependency management system (SPM, CocoaPods, etc.) and commit lock files to enable vulnerability scanning.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.