Before:

    let process = Process()
    process.executableURL = URL(fileURLWithPath: "/bin/ls")

    let pipe = Pipe()
    process.standardOutput = pipe

    try! process.run()
    process.waitUntilExit()
    let data = pipe.fileHandleForReading.readDataToEndOfFile()
    if let output = String(data: data, encoding: .utf8) {
        print(output)
    }

    let result = try await run(
        .name("ls"),
        arguments: ["-1"],
        output: .string(limit: 1 << 20)
    )
    print(result.standardOutput ?? "")

The Swift team did just release Subprocess, but it doesn't break hugely new ground. Swift has had API's for running system processes, and the best wrapper has been the Shwift library[1] which supports async operations and bash-like syntax for captures.

Wrapping tools with static functions that make convenient choices is helpful, but the real benefit comes with using type-safe API's - e.g., records for git-log output, enumerations for configuration, etc.

For the update-build-and-run dance, there are tools like clutch [2]. It helps most when you have a bunch of scripts that benefit from common (wrapping) libraries - as with builds, processing pipelines, etc. - because the common code doesn't need to be re-built, only the script.

- [1] shwift: https://github.com/GeorgeLyon/Shwift

- [2] clutch: https://github.com/swift-nest/clutch

Unless it's cashed, of course, then you get the extra overhead on first run, but lower overhead on at the subsequent runs? This is even mentioned in the article, so what's the issue in this specific peculiarity?