apple/swift-system

Swift System is a cross-platform library providing a modern, type-safe API for low-level system operations, including file handling, path manipulation, and error management. It supports multiple operating systems and architectures through a C compatibility layer and a CMake build system, ensuring consistent behavior across Unix-like systems, Windows, and WASI. The library also offers advanced features such as asynchronous I/O via Linux's io\_uring and robust testing infrastructure for syscall mocking and cross-platform validation.

7 changes.

This period marks the initial release of the Swift System library, introducing core APIs for cross-platform file handling, error management, and path manipulation. The work included establishing a C compatibility layer and static library build, alongside comprehensive test coverage to ensure correctness across multiple operating systems.

6 changes.

This period focused on modernizing the project's infrastructure by introducing a CMake build system and comprehensive multi-platform CI configurations. Significant development effort was directed toward expanding the API surface, including the addition of a strongly-typed file system metadata layer and a new IORing interface for Linux. These features were supported by internal refactoring to improve cross-platform compatibility and the implementation of robust testing mechanisms for syscall tracing and import visibility.

The CSystem include directory now provides a platform-specific compatibility layer for Swift System. This includes platform headers (Darwin, FreeBSD, Linux, WASI, Windows) that expose necessary C constants and structures, such as a compatibility macro for \O\_CLOFORK\ on Apple and FreeBSD, and a modified \dirent\ struct for WASI to ensure Swift importability. It also includes a custom \io\_uring.h\ header that defines fallback structures and feature macros for older Linux kernels or static SDKs where the system header is missing or incomplete, alongside a module map to expose these headers to Swift.

Sources/CSystem/include · high confidence

Introduces a CMake-based build system for the Swift System library, enabling integration with Swift Package Manager (SwiftPM) and other CMake consumers. The new build infrastructure includes modules to detect and map host architectures (including Windows ARM64, RISC-V, and various ARM/x86 variants) and operating systems, as well as logic to install Swift module files (.swiftmodule, .swiftdoc) into standard directories using the correct Swift module triple. This allows the library to be built and installed as a native CMake target (SwiftSystem::SystemPackage) alongside its Swift components.

cmake · high confidence

The project now includes automated CI job definitions for the \swift-system\ repository, enabling builds on macOS, Ubuntu 22.04, and Windows Server 2019. These configurations cover Swift versions 5.9, 5.10, and 6.0, as well as nightly builds for the main branch, ensuring the package is tested across these environments.

.swiftci · high confidence

This change introduces the Swift System library, providing a modern, type-safe API for system-level operations. It adds the \Errno\ struct for strongly-typed error numbers with deprecation of raw C constants, and \FileDescriptor\ for managing file handles, including standard input/output/error and access modes. The library includes \FileOperations\ for opening, closing, and seeking files, \FilePermissions\ for managing Unix-style access rights, and \FileHelpers\ for utilities like \closeAfter\ and \writeAll\. It also introduces \SystemString\ and \PlatformString\ for handling platform-native character encodings (UTF-8 on Unix, UTF-16 on Windows) and \MachPort\ for managing Mach port rights on Darwin systems. The CMake build system is added to support building the library outside of Swift Package Manager.

Sources/System · high confidence

This change introduces the \FilePath\ type, providing a unified, cross-platform way to represent and manipulate file system paths. The API automatically normalizes separators (converting forward slashes to backslashes on Windows) and enforces invariants at construction. It includes syntactic operations such as accessing the path \root\, iterating over \components\, and checking if a path is absolute or relative. The implementation supports Windows-specific path forms (traditional DOS, UNC, and device paths) alongside standard Unix paths, and adds support for creating and managing temporary directories securely across platforms.

Sources/System/FilePath · high confidence

This change introduces a new \IORing\ API for Linux, gated behind the \compiler(\>=6.2)\ and \$Lifetimes\ feature flags. It provides a structured interface for asynchronous I/O using the \io\_uring\ subsystem, including request types for file operations (open, read, write, close, unlink), cancellation, and polling. The implementation includes a \Completion\ struct to handle results and flags, a \PollEvents\ option set for monitoring file descriptor states, and internal utilities for interacting with the kernel ring buffers. This API is designed to work with Swift's ownership and lifetimes model, offering a modern, safe alternative to traditional POSIX I/O for supported platforms.

Sources/System/IORing · high confidence

Introduces new Swift types for file system metadata in the \Sources/System/FileSystem\ directory, including \Stat\ (a wrapper for the C \stat\ struct), \FileFlags\ (for file-specific flags on Darwin, FreeBSD, and OpenBSD), \FileMode\ (for C \mode\_t\), \FileType\ (for file type bits), and identifiers like \UserID\, \GroupID\, \DeviceID\, and \Inode\. These types provide a strongly-typed, safe API for accessing file system information, available from System 1.7.0 on Unix-like platforms.

Sources/System/FileSystem · high confidence

The CSystem module is now built as a static library via CMake, ensuring the C shim source (shims.c) is compiled and headers are installed for system use. This change introduces C wrappers for the POSIX \pipe2\ and \dup3\ APIs, providing native support on Linux, FreeBSD, and macOS (27+), while returning \ENOSYS\ on platforms lacking these functions. It also adds platform-specific header includes for Windows, WASI, and Darwin to support cross-platform system calls.

Sources/CSystem · high confidence

The internal implementation layer has been reorganized to improve cross-platform support and testability. A new CInterop module centralizes platform-specific type definitions (such as mode\_t and character encodings) and provides a back-deployed stat() wrapper for migration compatibility. Platform-specific logic for errno, syscalls, and string handling is now consolidated in dedicated internal files (Constants, Exports, Syscalls), with specific fixes for Android nullability and Windows file operations. Additionally, a new MockingDriver subsystem has been added to enable syscall tracing and error injection during testing.

Sources/System/Internals · high confidence

Added compile-only test to detect MemberImportVisibility regressions; Added comprehensive test coverage for FilePath parsing, components, and decoding; Expanded test coverage for Swift System core APIs.

The Package.swift manifest has been updated to require Swift 6.1 (via the swift-tools-version comment) and explicitly set the package's swiftLanguageModes to .v6. This change ensures that consumers of the swift-system library build with the Swift 6 language mode, which includes stricter concurrency and type-checking rules. The manifest also configures availability macros for various macOS, iOS, watchOS, tvOS, and visionOS versions, and enables the MemberImportVisibility experimental feature for specific test targets to verify C member visibility.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 64 → 63 (-0.4)
• Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 88 → 87 (-0.5)
• Architecture 91 → 97 (+6.5)
• Maturity 57 → 57 (+0.0)
• Readiness 52 → 55 (+2.8)
• Security 85 → 85 (+0.0)
• Performance 76 (new)

• Dependency hygiene PARTLY measured — SwiftPM pinning read, dependency currency NOT established
• Hotspot: Sources/System/FileSystem/Stat.swift (Sources/System/FileSystem/Stat.swift)
• No assertions: testInit (Tests/SystemTests/IORingTests.swift)
• Off-boarding risk: anonymized user #1

• Coverage not measured — Swift suite
• Duplicate operations: seek and lseek have identical signatures and semantics. lseek is the POSIX name, seek is the common C++/Java name, but exposing both creates confusion about which to use.
• Duplicated block (10 lines × 2) (Sources/System/FileOperations.swift)
• Duplicated block (18 lines × 2) (Sources/System/Internals/WindowsSyscallAdapters.swift)
• Duplicated block (20 lines × 2) (Sources/System/Internals/WindowsSyscallAdapters.swift)
• Duplicated block (8 lines × 2) (Sources/System/FileDescriptor.swift)
• Duplicated block (9 lines × 2) (Sources/System/FileOperations.swift)
• FunctionTooLong: WindowsSyscallAdapters.swift._createSecurityDescriptor (Sources/System/Internals/WindowsSyscallAdapters.swift)
• Hotspot: Sources/System/IORing/IORequest.swift (Sources/System/IORing/IORequest.swift)
• IORing.swift.setUpRing (cognitive 21) (Sources/System/IORing/IORing.swift)
• Inconsistent abstraction level: duplicate is a high-level wrapper, while dup, dup2, and dup3 are direct POSIX syscalls exposed as methods. This mixes idiomatic API with raw syscall bindings without clear distinction.
• Inconsistent parameter naming and structure: The first overload uses a boolean followTargetSymlink which is semantically equivalent to a specific flag (likely O_NOFOLLOW or similar in stat context), but it is not exposed as a Flags enum. This forces users to choose between a simple boolean API and a complex flags API for the same operation.
• Inconsistent return type and naming: pipe and pipe(options:) return a tuple of two descriptors, while pipe2() returns a single FileDescriptor. This is likely due to pipe2 being a Linux-specific syscall that returns a single fd with flags, but the API design is inconsistent with the standard pipe family.
• Off-boarding risk: anonymized user #1
• Skipped test: testBlockingConsumeCompletionWithTimeoutOnIdleRing (Tests/SystemTests/IORingTests.swift)
• Skipped test: testInit (Tests/SystemTests/IORingTests.swift)
• Skipped test: testNop (Tests/SystemTests/IORingTests.swift)
• Skipped test: testOpenReadAndWriteFixedFile (Tests/SystemTests/IORingTests.swift)
• Skipped test: testPathBufferLifetimeAcrossLinkedRequests (Tests/SystemTests/IORingTests.swift)
• Skipped test: testPathBufferLifetimeAcrossPrepareSubmit (Tests/SystemTests/IORingTests.swift)
• …and 10 more

• 12 commits — 12 feature/other, 0 fixes

• Sources/System — 7 commits
• (repo) — 3 commits
• (root) — 1 commit
• .github/workflows — 1 commit

• change: Add missing @inlinable
• change: Add unavailable/renamed hints for C names
• change: Address review feedback
• change: Doc comment updates
• change: Make internal isMultiShot default match public API
• change: Merge branch 'release/1.8.x' into main
• change: Merge pull request #273 from apple/fb-io-uring-poll-add
• change: Merge pull request #388 from apple/ospobot/code-of-conduct
• change: Remove PollEvents.allEvents and use internal Event enum for testing
• change: Replace repo-level CODE_OF_CONDUCT file with the inherited org-wide Code of Conduct in .github repo.
• change: Smaller touch ups
• change: [ci] update github actions (#389)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

apple/swift-system was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.