# XCLogParser for Xcode Build and Test Log Analysis

> XCLogParser converts Xcode and xcodebuild xcactivitylog files into JSON, build reports, issue lists, unit test results, and Chrome Trace output. It is best suited to macOS build pipelines and developers who need Xcode log data outside Xcode.

**MobileNativeFoundation/XCLogParser** — Tool to parse Xcode and xcodebuild logs stored in the xcactivitylog format

- Repository: https://github.com/MobileNativeFoundation/XCLogParser
- Stars: 1,853 · Forks: 139
- Language: Swift
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mobilenativefoundation-xclogparser

## Why XCLogParser Handles Xcode Log Data

XCLogParser addresses a practical gap in Xcode-based development: build and test logs are stored in Apple's binary `xcactivitylog` format, which is not convenient for direct inspection, scripts, or historical analysis. The project parses the `SLF` serialization format used by Xcode and `xcodebuild`, then converts that content into files that software can read.

The intended audience includes developers investigating where a build spends its time, engineers collecting unit test results, and teams feeding build data into tools that run outside Xcode. The repository also describes continuous delivery of historic analysis as a use case. That makes the executable relevant to build automation, but its scope remains tied to logs produced by Apple's toolchain. It is not a general-purpose parser for arbitrary compiler output.

The CLI has three main jobs. `dump` converts an entire activity log to JSON, `parse` produces analysis reports, and `manifest` converts `LogStoreManifest.plist` to JSON. This separation matters when designing automation. A caller that needs every recorded field can retain a raw JSON representation, while a report-oriented caller can select a narrower format.

## From xcactivitylog to Machine-Readable Reports

Build logs are created by Xcode or `xcodebuild` a few seconds after a build finishes. They normally appear under a path shaped like `DerivedData/YourProjectName-UUID/Logs/Build`. The README describes each log as a binary file using `SLF` serialization and compressed with gzip. XCLogParser handles that representation and exposes its contents as JSON or report formats.

The `parse` command supports `json`, `flatJson`, `summaryJson`, `chromeTracer`, `issues`, and `html`. This menu reflects two different needs. `issues` is suited to warnings, errors, and test-related findings, while `html` creates a view intended for direct inspection after a build. `chromeTracer` maps log timing data into a format associated with tracing tools, and the JSON variants provide alternatives for downstream scripts. The repository does not document every field in each output, so an adopter should inspect a sample report before depending on a particular schema.

Log discovery is also part of the design. The caller can pass `--file` for a known path or `--project` for a project name. With `--project`, the executable searches `DerivedData` for the latest build log in a folder beginning with that name. `--strictProjectName` restricts matching. The README warns that Xcode 11 and later `xcodebuild` needs `-resultBundlePath` to generate `xcactivitylog` build logs.

## Installing XCLogParser and Producing an HTML Report

The README offers three documented installation paths: build through Rake, use Swift Package Manager directly, or install Homebrew's `xclogparser` package. Homebrew is the shortest route when that formula is available in the user's environment.

```bash
brew install xclogparser
```

After installation, confirm that the executable is available on `PATH`, then run the documented parse command with the `html` reporter. This is a real first use because it produces a browser-oriented artifact from Xcode's binary log rather than merely printing the CLI help.

```bash
xclogparser parse --project MyApp --reporter html
```

The parser should generate its HTML output according to the reporter's documented behavior. The README's Xcode integration uses a project name and an output-oriented invocation, so this second form is useful when a log path is already known:

```bash
xclogparser parse --project MyApp --reporter html
```

For installation outside Homebrew, the repository documents `rake build[debug]`, `rake build[release]`, and `rake install`. The last command installs the executable in `/usr/local/bin`. Source builds are therefore also a supported path, although the README does not spell out the underlying Swift Package Manager invocation.

## Automating XCLogParser from an Xcode Scheme

XCLogParser can run as a post-action script in Xcode. The README instructs users to open the scheme editor, expand the Build panel, add a post-action run script, and invoke `xclogparser`. The script assumes that the executable is installed and can be found through `PATH`.

```bash
xclogparser parse --project MyApp --reporter html
```

Because Xcode executes a scheme action in a temporary directory, the README suggests opening the generated folder when the output should be inspected immediately:

```bash
open MyAppLogs
```

This arrangement has an important operational cost. Xcode may wait for subprocesses to exit before completing the build, so a long parsing job can delay the apparent completion message. The documented workaround runs the parser in the background and closes its standard streams. The launcher forwards arguments to the selected executable:

```sh
#!/bin/sh

executable=$1
shift;
$executable "$@" <&- >&- 2>&- &
```

A post-action is not executed after a build failure. For parsing that must run on failed builds, the README points to the scheme attribute `runPostActionsOnFailure`, setting it to `YES` in the `BuildAction` XML. That is a documented Xcode-specific setting, but the README does not describe how to locate or safely edit the scheme file across different Xcode versions.

## Raw Dumps and Manifest Inspection

The `dump` command is the most direct way to inspect what XCLogParser extracts from an activity log. It writes the complete log representation to JSON, which is useful when a downstream program needs more than the selected report views. The documented examples accept either a direct file path or a project name:

```bash
xclogparser dump --file path/to/log.xcactivitylog --output activity.json
xclogparser dump --project MyProject --output activity.json --redacted
```

The `--redacted` option is documented in the second example, while the README excerpt does not provide a detailed description of its fields or scope. That omission matters for adoption. A team should not assume that redaction removes every possible identifier until it checks the resulting JSON against its own privacy requirements.

The `manifest` command handles a related indexing file. Xcode places `LogStoreManifest.plist` beside build logs, and the README says it can be monitored to detect new logs. Converting it to JSON can help a watcher feed newly completed activity into another system. The project documentation does not specify a polling interval, file-watch command, or manifest JSON schema, so those parts require an implementation decision outside the parser's documented interface.

## Where XCLogParser Is the Wrong Tool

XCLogParser is constrained by both its input format and its operating environment. Its parser targets Xcode and `xcodebuild` logs in `xcactivitylog`, not CI transcripts from other build systems, compiler diagnostics delivered only as text, or arbitrary compressed archives. If a pipeline cannot produce an `xcactivitylog`, changing the reporter will not make the tool applicable.

The project is also not a replacement for Xcode itself. It extracts and organizes log data, but the README does not claim that it reproduces every Xcode interface, reconstructs arbitrary DerivedData state, or performs a build. A user who needs to diagnose a failed build interactively still needs the relevant Xcode or `xcodebuild` diagnostics alongside the generated report.

There is also a tradeoff around automation timing. Running parsing in a post-action can delay Xcode while subprocesses finish, while backgrounding it hides errors more easily because Xcode silences errors from post-action run scripts. The documented background launcher addresses the delay but makes operational checks important: a CI job should verify the expected output file rather than rely only on Xcode's build result.

For comparison, a tool that consumes standard JSON build telemetry would avoid the binary parsing step, but it would not read historical Xcode activity logs in their native format. XCLogParser is more appropriate when the source of truth is `xcactivitylog`; JSON-first tooling is more appropriate when a build system already emits structured events.

## Release History and Apache-2.0 Use

The repository lists recent releases `v0.2.47`, `v0.2.48`, and `v0.2.49`, with `v0.2.49` dated 2026-07-07. The last push was on 2026-07-07. The repository is not archived, so the available maintenance signal is the recent release and push history rather than an archive notice.

The repository identifies Apache-2.0 as its license. That designation matters for organizations reviewing reuse and distribution, but this article does not provide legal advice. The repository includes `LICENSE` and `NOTICE` files, which are the appropriate files to inspect when assessing the exact permissions and attribution obligations for a deployment.

The codebase includes `Package.swift`, Swift tests, CI configuration, a Dockerfile, and build scripts. The Dockerfile uses `swift:6.0`, installs `zlib1g-dev` and `ruby`, then builds with `swift build`. That gives maintainers a container-oriented build route, although the README does not publish a complete image tag or a supported deployment procedure for using the resulting container in CI.

## Conclusion

XCLogParser fits developers and CI systems that consume Xcode logs outside the Xcode interface, especially when historical analysis or machine-readable output matters. It is a poor choice for unsupported log formats, non-Apple build systems, or users needing documented reverse deployment workflows. Verify first that the environment can install the Swift executable, that the input `xcactivitylog` is available, and that the selected reporter matches the automation's required output.

## FAQ

### How do I install XCLogParser?

The README documents `brew install xclogparser`, Rake build and install commands, and Swift Package Manager use. Homebrew is the most direct documented option when the formula is available.

### What file does XCLogParser parse?

XCLogParser parses Xcode and `xcodebuild` logs stored in the `xcactivitylog` format. The README identifies the underlying representation as `SLF` serialization compressed with gzip.

### Can XCLogParser generate an HTML build report?

Yes. The documented `parse` command accepts the `html` reporter.

## Sources

- [Issues](https://github.com/MobileNativeFoundation/XCLogParser/issues)
- [License: Apache-2.0](https://github.com/MobileNativeFoundation/XCLogParser/blob/master/LICENSE)
- [MobileNativeFoundation/XCLogParser on GitHub](https://github.com/MobileNativeFoundation/XCLogParser)
- [README](https://github.com/MobileNativeFoundation/XCLogParser/blob/master/README.md)
- [Releases](https://github.com/MobileNativeFoundation/XCLogParser/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mobilenativefoundation-xclogparser