{"id":49853,"date":"2025-10-30T19:21:35","date_gmt":"2025-10-30T23:21:35","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49853"},"modified":"2025-12-01T10:04:16","modified_gmt":"2025-12-01T15:04:16","slug":"swift-6-2-subprocess","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/10\/30\/swift-6-2-subprocess\/","title":{"rendered":"Swift 6.2: Subprocess"},"content":{"rendered":"

Holly Borla<\/a>:<\/p>\n

Swift 6.2 introduces a new Subprocess<\/code> package that offers a streamlined, concurrency‑friendly API for launching and managing external processes.<\/p>\n<\/blockquote>\n\n

SF-0007<\/a>:<\/p>\n

The existing Foundation API for spawning a process, NSTask<\/code>, originated in Objective-C. It was subsequently renamed to Process<\/code> in Swift. As the language has continued to evolve, Process<\/code> has not kept up. It lacks support for async\/await<\/code>, makes extensive use of completion handlers, and uses Objective-C exceptions to indicate developer error. This proposal introduces a new package called Subprocess<\/code>, which addresses the ergonomic shortcomings of Process<\/code> and enhances the experience of using Swift for scripting and other areas such as server-side development.<\/p><\/blockquote>\n\n

It’s currently available as a package<\/a>, rather than being built into the OS, so the API may not be fully stable, but you can use it on older OS versions.<\/p>\n\n

One of the issues with NSTask<\/code>\/Process<\/code> is that the simple API works for small amounts of input\/output but (unbeknownst to many, even some experts<\/a>) hangs once you exceed the OS’s buffer size. There are ways around this, but they are awkward (though you can hide them in a helper class). As Christian Tietze<\/a> (Mastodon<\/a>) writes:<\/p>\n

Helge Heß pointed out<\/a> that naive usage of Pipe<\/code> in child Process<\/code>es can break your program if you pipe too much data.<\/p>

[…]<\/p>

If the data is larger than the pipe buffer, you need to drain the corresponding FileHandle<\/code> with repeated read calls. (Or provide data larger than 64KiB with repeated write calls, respectively.)<\/p>

If you try to send\/receive the whole buffer in one go, from a user’s perspective, your program will freeze, and the read call never return. As a CLI app, it’ll never terminate.<\/p><\/blockquote>\n\n

Subprocess<\/code> seems to be designed to transparently handle this. You can specify the output size limit (and the encoding, if you want a string output), and it will collect the pieces of output as they arrive.<\/p>\n\n

I’ve been using Swift to write scripts, and scripts often need to run shell commands. Unfortunately, Subprocess<\/code> is currently cumbersome to use for scripting, as Jacob Bartlett<\/a> writes:<\/p>\n

These simple scripts have ludicrous amounts of overhead for what are trivial one-liner operations in the bash shell. Bear with me, because later we’ll look at where Swift subprocess can actually work well, in a more complex workflow.<\/p>

The additional overhead of requiring a full SwiftPM project, compared to a Bash script, makes it incredibly cumbersome for simple workloads. Also, it’s still not an actual script, so it’ll always require a compilation (and potentially dependency resolution) overhead whenever your code changes.<\/p>

On the other hand, the syntax, type safety, and composability of Swift code work pretty nicely when you have complex automation<\/strong> workflows<\/strong> to orchestrate, build, and run on demand.<\/p><\/blockquote>\n\n

Previously:<\/p>\n