A long time ago, I wrote a post on how to build a simple App using SwiftUI that would run a shell command. Amazingly, the tutorial still works!
This is particularly useful for MacAdmins, because we sometimes want to provide a simple UI for some command or script. However, some things have changed since I wrote this tutorial three years. While the code still “works,” there are some things that can be improved. Also, when I wrote the original post, there were some features I didn’t expand upon, because the post was already very long, and, to be honest, back then, I didn’t really know how they worked, myself.
When I re-visited this earlier because of a question in the MacAdmins Slack, I was really surprised that I didn’t need to update code to make it work. That said, there are the matters I didn’t explain last time. Also Swift has changed in some ways. That means it is time for the second part.
You can get the sample code from the first part as a starting point.
Get the output of the command
In the first part, we ran the say command, which doesn’t have a text output. Often times we want to run shell commands to get information from the command’s standard output (or sometimes standard error). To grab the output of commands, we need to prepare the Process object, which means we cannot use the convenience method Process.run() any more.
The say command has an option to change the voice being used. You can list the names of voices available to the say command by running say -v '?' in Terminal. We’d like to get that output and populate a menu with the available voices in our UI.
Note: the output of the say -v '?' command does not show most of the modern voices available in macOS. Most of the voices listed are quite old, funny, and, to be honest, awful. As has been mentioned before, I am using the say command as a convenient example for a shell command. If you want proper speech synthesis in your app, you should not use the say command but the proper speech synthesis API.
We will start out experimenting with code in a macOS Playground in Xcode and later add it to the app from the first part. When you create a new Playground in Xcode (File > New > New Playground), make sure you select ‘macOS’ for the platform above the template picker and then ‘Blank’ as the template.
Start with this code:
let process = Process()
process.launchPath = "/usr/bin/say"
process.arguments = ["-v", "?"]
let outPipe = Pipe()
process.standardOutput = outPipe
process.terminationHandler = { process in
let outData = outPipe.fileHandleForReading.readDataToEndOfFile()
let output = String(data: outData, encoding: .utf8) ?? ""
print(output)
}
try? process.run()
process.waitUntilExit()
You will recognize some of the code from the first part of this tutorial. We create a Process object and set its launchPath and arguments. Note that the Process.run() convenience method, which we used in the first part, takes a URL to define the executable, but the launchPath is a String containing the path to the executable. We also (this is the new part) create a Pipe and set it as the standardOutput of the process.
The process will run the say command asynchronously. Since we want to work with the output , we have to give the process some code to execute when the command is done. We set this terminationHandler to a closure. The code in this closure grabs the data from pipe we connected to standardOutput of the process, converts it to a String and prints it.
At the end of our code, we tell the process object to run(). The waitUntilExit() is necessary here, because that is all this particular playground code does and we want to be sure that the command and the termination handler get a chance to do their work, before the code ends. In an app, where many things may be happening at the same time, you usually will not use waitUntilExit(). We will see that later when we implement our solution in SwiftUI.
Many outcomes
This code grabs the standard out from the command. Unix commands have different results that can be interesting. Some commands print to standard error instead of (or together with) standard out. All unix commands also have an exit code, which should return 0 for successful runs and a non-zero value for failures. Some commands use different non-zero value to give information for different errors.
All of this is available from Process objects. However, you have to set up the pipes and connections and get the data back in the termination handler, and the code gets quite complicated and tedious to set up. We have the seen the Process type has a convenience method to create and run a command without the pipes. I don’t know why it doesn’t have a convenience method when you are interested in all the data, but the good news is, we can create an extension to build our own.
Replace the code in the playground with the following:
import Foundation
extension Process {
@discardableResult
static func launch(
path: String,
arguments: [String] = [],
terminationHandler: @escaping (Int, Data, Data) -> Void
) throws -> Process {
let process = Process()
let outPipe = Pipe()
let errorPipe = Pipe()
process.standardOutput = outPipe
process.standardError = errorPipe
process.arguments = arguments
process.launchPath = path
process.terminationHandler = { process in
let outData = outPipe.fileHandleForReading.readDataToEndOfFile()
let errorData = errorPipe.fileHandleForReading.readDataToEndOfFile()
let exitCode = Int(process.terminationStatus)
terminationHandler(exitCode, outData, errorData)
}
try process.run()
return process
}
}
let process = try? Process.launch(
path: "/usr/bin/say",
arguments: ["-v", "?"]
) { exitCode, outData, errData in
let output = String(data: outData, encoding: .utf8) ?? ""
print(output)
}
process?.waitUntilExit()
You will recognize the code from our first example in the launch function in the extension. But here, we have added the configuration for a second Pipe for standardError, in the closure we get the Data for the standard out, standard error and the exit code and pass them in to the closure passed in a termination handler.
This method simplifies using the Process type. We just have to pass in the path to the command and the arguments array and give a closure that is called when the command completes.
async/await
But it still uses a closure for the termination handler. This breaks our code into different fragments that are not executed in the order they appear in. Since macOS Monterey 12 and iOS 15, Swift has had a concurrency feature called async/await. With this, your code appears in a more natural order.
When a function has the await marker, the system knows to suspend the code at that point until the function returns a result. While this code is “on hold” other threads or tasks can run, such as the UI handling, so your process or app isn’t blocked. When the function returns, the code continues after the function, so the code that processes the output of the function comes in the logical order, which makes it easier to read and understand.
For some reason, the Process type has not yet been updated to use this new feature. We can however, add this functionality using an extension. Add this method to the extension:
static func launch(
path: String,
arguments: [String] = []
) async throws -> (exitCode: Int, standardOutput: Data, standardError: Data) {
try await withCheckedThrowingContinuation { continuation in
do {
try launch(path: path, arguments: arguments) { exitCode, outData, errData in
continuation.resume(returning: (exitCode, outData, errData))
}
} catch let error {
continuation.resume(throwing: error)
}
}
}
If you want to get more detail how async and await work, I recommend the WWDC session “Meet async/await in Swift” from WWDC 2021.
With this, we can change our code to run the say command to:
guard let (exitCode, outData, errData) = try? await Process.launch(
path: "/usr/bin/say",
arguments: ["-v", "?"]
) else { exit(0) }
let output = String(data: outData, encoding: .utf8) ?? ""
print(output)
The code is now in a more sensible order. If you can afford macOS Monterey as a minimum system requirement, you should consider adopting async/await.
Now that we have our output of the command, we have to parse out the names of the voices. This code will turn the output of the say into an Array of names, ignoring the language code and sample text:
func parseVoices(_ output: String) -> [String] {
output
.components(separatedBy: "\n")
.map {
$0
.components(separatedBy: "#")
.first?
.trimmingCharacters(in: .whitespaces)
.components(separatedBy: CharacterSet.whitespaces)
.dropLast()
.filter { !$0.isEmpty }
.joined(separator: " ")
?? ""
}
.filter { !$0.isEmpty }
}
So we can add these lines to get an Array of `voices:
let voices = parseVoices(output)
print(voices)
You can find the stages of code for the playground in this gist.
Updating the app
Now that we have assembled all the pieces working in a playground, we can move on to putting these pieces in our SwiftUI app. The goal is to have a popup menu with all the voices above the field where you can enter text.
We will be using some features that were introduced in macOS Monterey 12.0. If you have built the project a while ago with an older version of macOS, the project may be set to build with older versions of macOS. To verify and, if necessary, update the deployment target for the project, select the blue project icon at the very top of the item sidebar, then select the gray “SayThis” icon under the “Targets” section. Then select “General” in the tab list. The second section is called “Minimum Deployments” and should show macOS 12.0 or later. When you change this from an older version, Xcode may prompt to update some other settings in the project, you can accept those.
First, we want to use the extension to the Process type we created in the playground earlier. Create a new file in the project (File > New > New File…), select “Swift File” from the templates, and name it ‘Process-launch’. Copy and paste the extension code from the playground (with both methods) to that file. You could have all the code in a single file, but it is cleaner and more maintainable to have one file per type or extension. This also allows you to copy that file to other projects to use it there.
Next we need two more state variables to track the state of the popup-menu that we are going to add. In the ContentView file, add these two lines right under the existing @State variables:
@State var voices: [String] = []
@State var selectedVoice: String = "Samantha"
The first is where we are going to store all the available voices that we parse from the output of say -v '?'. The second variable will store the current selection.
Next, we will insert the popup menu for the voices into the UI. In the body, insert this below the title and above the HStack:
Picker(selection: $selectedVoice, label: Text("Voice:")) {
ForEach(voices, id: \.self) { Text($0) }
}
First we create a Picker view, which is not really proper terminology for macOS. But since SwiftUI is designed to share objects across all platforms, a ‘Picker’ will render as a popup menu in macOS. We attach the selectedVoice state variable to the selection of the picker. Then, we loop through all the items in the voices state variable to add them to the picker.
At this point, you should see the popup menu in the preview and when you run the project. You cannot select anything from it, though, which makes sense as the voices array is empty.
We need to populate the voices array before the UI appears. SwiftUI offers a special modifier to do this. You can attach a .task modifier to any view and its closure will be run asynchronously once, before the view appears for the first time. Add this code to the end of the VStack block, right below the line that reads .frame(maxWidth: .infinity, maxHeight: .infinity):
.task {
guard let (_, outData, _) = try? await Process.launch(
path: "/usr/bin/say",
arguments: ["-v", "?"]
) else { return }
let output = String(data: outData, encoding: .utf8) ?? ""
voices = parseVoices(output)
}
You also need to copy the parseVoices() function from the test playground and add it to the ContentView struct.
This will populate the popup menu with all the voices. Build and run to test. It will still not actual use the selected voice. We need to update the runCommand() method to:
func runCommand() {
let arguments = [message, "-v", selectedVoice]
let executableURL = URL(fileURLWithPath: "/usr/bin/say")
self.isRunning = true
try! Process.run(executableURL, arguments: arguments) { _ in
self.isRunning = false
}
}
We have achieved what we set out to do. You can find the project with all the code for this point here.
Refinements
However, there are some refinements and improvements that we can and should still add to the code.
First, the runCommand() function still uses the old convenience handler with a termination handler. We can change it to use our new await Process.launch():
func runCommand() async {
let arguments = [message, "-v", selectedVoice]
self.isRunning = true
let _ = try? await Process.launch(path: "/usr/bin/say", arguments: arguments)
self.isRunning = false
}
This will now generate an error in the Button because we have changed the runCommand() function to be async. Change the code of the Button to
Button("Say") {
Task {
await runCommand()
}
}
.disabled(isRunning)
By wrapping the await runCommand() function in a Task { } we are telling the system that this code should run in the background and not return immediately. This is necessary to run code blocks with async functions from UI elements.
The say command will use the voice set in the system settings when no -v option is given. We want to provide a way to recreate that behavior in our UI. We can add items to the Picker by adding elements before the ForEach:
Picker(selection: $selectedVoice, label: Text("Voice:")) {
Text("System Default").tag("System Default")
Divider()
ForEach(voices, id: \.self) { Text($0) }
}
Also change the default value of the selectedVoice variable to "System Default".
Then we have to change the runCommand() method to only use the -v and voice name arguments when their value is not “System Default”
func runCommand() async {
var arguments = [message]
if selectedVoice != "System Default" {
arguments.append(contentsOf: ["-v", selectedVoice])
}
self.isRunning = true
let _ = try? await Process.launch(path: "/usr/bin/say", arguments: arguments)
self.isRunning = false
}
You can find the code for this here.
Out of the Sandbox
The say command provides a fun example to play around with. You will probably already have plenty of ideas that you want to try out. There is one thing that might trip you up here: sandboxed apps do not get access to all available command line tools. If you want to run such ‘prohibited’ commands, you will need to remove the sandbox configuration from the app.
Better Extension
The extension I put together here will work in most situations, but there are conditions where different parts might not work well. Quinn the Eskimo has published this code which goes further and is probably “even more” thread safe.
Launching commands is an “expensive” task. You should always do some research to see if there is some framework that can give you access to the same functionality natively in Swift. Nevertheless, sometimes it might be necessary, and sometimes it might just be easier to call out to an external command.
This tutorial should help you along the way of using these tools effectively.
