swift-corelibs-xctest is the open source XCTest that runs on every Swift platform

The same XCTest on Linux, Windows and the web

The XCTest library is designed to provide a common framework for writing unit tests in Swift, for Swift packages and applications.

The reason this repository exists is platform coverage. This version of XCTest implements the majority of unit testing APIs included in XCTest from Xcode 7 and later, and its goal is to enable your project's tests to run on all the platforms Swift supports without having to rewrite them.

That is a bigger deal than it sounds. The XCTest you use in Xcode is tied to Apple platforms, and a Swift package with server-side or cross-platform code usually ends up with no test coverage outside a Mac, or with a second test framework, which means duplicating every assertion helper and every fixture. Having one XCTest that compiles everywhere removes that split.

The organisation is swiftlang, the project is part of the Swift open source project, and the copyright line in the Dockerfile is Copyright 2026 Apple Inc. and the Swift project authors, licensed under Apache License v2.0 with Runtime Library Exception. The Runtime Library Exception is the clause that matters for a library: it lets you link this into a proprietary application without the Apache terms applying to your code.

The release history is tied to the Swift release train rather than to this library's own version. The listed releases are swift-6.1-RELEASE in April 2025, swift-6.1.1-RELEASE in May 2025 and swift-6.4.0-RELEASE in September 2026, so XCTest ships as part of a Swift toolchain release and does not have an independent version of its own.

Under Swift Package Manager, swift test is the whole workflow

For most users of this library, the interface is the Swift Package Manager and not the XCTest API directly.

The Swift Package Manager integrates directly with XCTest to provide a streamlined experience for unit testing SwiftPM packages. If you are using XCTest within a SwiftPM package, unit test files are located within the package's Tests subdirectory, and you can build and run the full test suite in one step by running swift test.

The test organisation itself is the classic XCTest shape. Your tests are organized into a simple hierarchy. Each XCTestCase subclass has a set of test methods, each of which should test one part of your code.

For general information, the README points at Apple's Testing with Xcode guide and the XCTest API documentation, and for the SwiftPM side it links the swift-package-manager repository.

That arrangement is why the library rarely appears in a Package.swift. A package that wants to be testable declares a test target, and the framework is supplied by the toolchain. The value of this repository is therefore in the toolchain rather than in a dependency you add by hand, which is worth knowing when you are trying to understand why your package's tests run on Linux when you did nothing special to make that happen.

Standalone use means writing your own main and calling XCTMain

When XCTest is used by itself, without SwiftPM, the behaviour changes in a way that surprises people coming from Xcode.

This version of XCTest does not use the external xctest CLI test runner included with Xcode to run tests. Instead, you must create your own executable which links libXCTest.so, and in your main.swift, invoke the XCTMain function with an array of the tests from all XCTestCase subclasses that you wish to run, wrapped by the testCase helper function:

XCTMain([
    testCase(TestNSString.allTests),
    testCase(TestNSArray.allTests),
    testCase(TestNSDictionary.allTests),
])

The XCTMain function does not return, and will cause your test executable to exit with either 0 for success or 1 for failure.

So the standalone path means the test binary is yours, built by your own build system, linked against the shared library, and it exits with a status code rather than reporting through an Xcode protocol. For a project that wants to run its tests in a container or on a device, that is a feature, because there is no Xcode test runner to work around.

The command line arguments are also more capable than the Xcode runner's. A particular test or test case can be selected to execute:

$ ./FooTests Tests.FooTestCase/testFoo                            # Run a single test method
$ ./FooTests Tests.FooTestCase                                    # Run all the tests in FooTestCase
$ ./FooTests Tests.FooTestCase/testFoo,Tests.FooTestCase/testBar  # Run multiple test methods

And tests can be listed instead of executed, either as text with --list-tests or as JSON with --dump-tests-json. The JSON output is a nested structure mirroring the test hierarchy, which is what a CI system would consume to work out what is available before running anything.

Building it means living on the Swift main branch

The contributing section is where the project's real constraints are, and they are strict.

To contribute, you need to be able to build this project and run its test suite. The easiest way is via the Swift build script, and you are told to follow the instructions in the Swift README to build Swift from source. This project is only guaranteed to build with the very latest commit on the Swift and swift-corelibs-foundation main branches, and you may update to the latest commits using the Swift utils/update-checkout script:

$ ../swift/utils/update-checkout

Three build routes follow. The recommended one is CMake and Docker, using the local build_script.py:

$ docker build -t swift-corelibs-xctest-docker:latest .
$ docker run -it -v ../../swift-project:/swift-project -w /swift-project/swift-corelibs-xctest swift-corelibs-xctest-docker \
      sh -c "cmake -G Ninja -B .build && cmake --build .build && \
      ./build_script.py test \
      --swiftc=/usr/bin/swiftc \
      --foundation-build-dir .build/ \
      .build/"

The Docker route assumes you have already cloned the entire Swift project into a folder named swift-project, because XCTest is built as part of the whole toolchain rather than standalone.

The Swift build script route is simpler if you already have the Swift project working, since you confirm you can build it using utils/build-script -R, then run ../swift/utils/build-script --preset corelibs-xctest.

The Xcode route exists for browsing files, using the XCTest.xcworkspace and the SwiftXCTest scheme, with the SwiftXCTestFunctionalTests scheme to run the tests. But the README warns that you must use an Xcode toolchain with an extremely recent version of Swift, that the website provides development snapshot toolchains, and that Swift development moves fairly quickly, so even a week-old toolchain may no longer work.

The escape hatch is the utils/build-toolchain script, and the README closes with the reassurance that the build script invocation always works regardless of which toolchains you have installed, and that the Xcode workspace exists only for the convenience of contributors.

The repository and the nightly Docker image

The top level of the repository is what you would expect for a Swift core library, and a couple of entries say something about the build.

There is CMakeLists.txt and a cmake/ directory, a Dockerfile, a build_script.py, and the usual Package.swift. Sources/ and Tests/ are the code and the test suite, and XCTest.xcodeproj/ and XCTest.xcworkspace/ are the Xcode projects. Info.plist is there for the macOS bundle, and .mailmap and .pep8 are contribution housekeeping files, the latter being the configuration for the Python formatting checks that the project applies to its build scripts.

The Dockerfile is worth reading because it shows the intended environment. It is based on swiftlang/swift:nightly-main-jammy, so the container runs a nightly Swift toolchain on Ubuntu Jammy, and it installs cmake, ninja-build, python3 and python3-pkg-resources. The build runs as a non-root user, with a group and a user created at group id 998, and the work directory is set to that user's home.

Using a nightly base image and a nightly compiler is consistent with the stated constraint that the project is only guaranteed to build with the very latest commit on the Swift main branch. A contributor who tries to build this against a released toolchain will hit failures that are about the toolchain rather than about XCTest.

The .github/ directory holds the CI configuration, and the Apache License v2.0 with Runtime Library Exception is named in the file header of the Dockerfile itself, which is the standard header for Swift project sources.

Editorial conclusion

swift-corelibs-xctest matters to a team whose package has to be tested on more than Apple platforms, because it is the reason swift test works everywhere, and it is not something most developers interact with directly since the framework is used through Swift Package Manager rather than as a dependency you wire up. Before contributing to it, read the contributing section, because the project is only guaranteed to build with the very latest commit on the Swift main branch and the Xcode route needs a toolchain that may already be too old. Verify first that the API surface you rely on is in the implemented set, since the README describes it as implementing the majority of the XCTest APIs rather than all of them.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. swiftlang/swift-corelibs-xctest on GitHub