SwiftUI: Command SwiftCompile failed with a nonzero exit code

That’s an interesting failure you’ve got there. Normally when I see this error it’s because the compiler has out’n’out crashed, and there’s at least some diagnostic info in the full build log. But in this case there’s just nothing. The compiler seems to have failed but produced no diagnostics.

Does the problem reproduce if you do a Product > Archive? That also creates a Release build, but it might be sufficiently different to either work, or yield more useful diagnostics.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I had not tried that actually so I just did and received a ton of compiler errors. I uploaded a new GIST of the errors. Why do I not receive these during a normal Run while in the Debug config?

I have done some additional testing. Since all of the Archive compiler errors I'm getting now exist within the #Preview macros used in the Views I removed them all. Once I deleted all of the #Preview macros in the app I could delete the SampleData.swift and PreviewContainer.swift files that the compiler wasn't finding.

Now those files don't exist and I can continue to build and run the app normally. However Release build still fail with the same compiler error and the Archive command fails with the same Command SwiftCompile failed with a nonzero exit code build error. Looking at the log (here) it looks like the same result as my Release builds - no details.

I don't understand why Archive was failing to build with all the #Preview macros - I'll have to circle back around and look at that later. At the moment though, both Release builds and Archive is failing with the same nonzero exit code failure.

The Swift compiler can build in a variety of different ways depending on how it’s invoked. And Xcode will definitely invoke things differently depending on whether you’re building to run or building to archive. I’ve not looked into the gory details here. If you want to do that, it’s all visible in the full build log.

I’d rather focus on this:

At the moment though, both Release builds and Archive is failing with the same nonzero exit code failure.

Well, that’s consistent at least |-:

This is one of those cases where you have to decide whether it’s worth your time diving into the rabbit hole. I see two paths forward:

• If you don’t need an immediate answer and you’re willing to share your source code with Apple, you could take your test project and put that in a bug report. If you do that, please post your bug number, just for the record.

• If you really need to get this sorted quickly, or you can’t share all your code with Apple, you can do more to investigate this at your end. See the second half of this reply.

The former is quick and easy. The latter is a lot more work, but in the process of isolating the issue you might come across a workaround.

If you decide to dig into this further, my suggestion is that you take the last few commands from your full build log and run them from Terminal. Use $? to see the exit status:

% true ; echo $?
0
% false ; echo $?
1

If that replicates the problem, and I have every reason to believe it will, you can take the failing command and tweak it to further isolate the issue.

These commands are super long, so it’s usually best to put each one into a script file so that you can edit them easily. Once you’ve nailed down the replication, start reformatting it for human consumption (-:

Notably, each command passes a lot of files to the compiler (65 by my count). An obvious isolation step is to remove files and see if that fixes the problem. If you do that, remember to remove each instance of the file. For example, the command contains:

• …/ColorsAllowed.swift

• -o …/ColorsAllowed.o

• -index-unit-output-path …/ColorsAllowed.o

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have been able to fully reproduce this issue in a sample app. The following code will build, and run on both a simulator and a device. It will also work in XCode preview. When I attempt to archive it or run a Release config, it fails with the nonzero error.

import SwiftUI

class MyModel {
    var name: String
    var children: [MyModel] = []
    
    init(name: String) { self.name = name }
}

struct MyModelPicker: View {
    private var items: [MyModel] = []
    
    init() {
        let foo = MyModel(name: "Foo")
        let bar = MyModel(name: "Bar")
        
        let people = MyModel(name: "People")
        let johnDoe = MyModel(name: "John Doe")
        let maryJane = MyModel(name: "Mary Jane")
        let childDoe = MyModel(name: "Child of Doe")
        
        johnDoe.children.append(childDoe)
        people.children.append(contentsOf: [ johnDoe, maryJane ])
        foo.children.append(bar)
        items = [ foo, people ]
    }
    var body: some View {
        List {
            ForEach(items, id: \.name) { item in
                getRowForUserList(item)
            }
        }
    }
    
    @ViewBuilder func getRowForUserList(_ list: MyModel) -> some View {
        if list.children.isEmpty {
            Text(list.name)
        } else {
            getRowForParent(list)
        }
    }
    
    @ViewBuilder func getRowForParent(_ list: MyModel) -> some View {
        DisclosureGroup(isExpanded: .constant(true)) {
            ForEach(list.children, id: \.name) { child in
                getRowForUserList(child)
            }
        } label: {
            Text(list.name)
        }
    }
}

struct ContentView: View {
    var body: some View {
        VStack {
            MyModelPicker()
        }
    }
}

#Preview {
    ContentView()
}

With this reproducible, I submitted bug report FB15926480 with this example project included. Within the getRowForParent function there is the following loop:

ForEach(list.children, id: \.name) { child in
    getRowForUserList(child)
}

Commenting out the getRowForuserList function call will allow archiving to complete successfully. It seems to be an issue with recursion of the views.

After some additional debugging, I have found that replacing the usage of @ViewBuilder with dedicated structs allows for archive builds to be created. I can copy the implementation of each ViewBuilder as-is with no changes and past them into structs. Release configuration and Archiving compiles successfully.

The revised code is below - again with no implementation changes other than pulling the code out of ViewBuilder and into a struct.

import SwiftUI

@Observable class MyModel {
    var name: String
    var children: [MyModel] = []
    
    init(name: String) { self.name = name }
}

struct MyModelPicker: View {
    private var items: [MyModel] = []
    
    init() {
        let foo = MyModel(name: "Foo")
        let bar = MyModel(name: "Bar")
        
        let people = MyModel(name: "People")
        let johnDoe = MyModel(name: "John Doe")
        let maryJane = MyModel(name: "Mary Jane")
        let childDoe = MyModel(name: "Child of Doe")
        
        johnDoe.children.append(childDoe)
        people.children.append(contentsOf: [ johnDoe, maryJane ])
        foo.children.append(bar)
        items = [ foo, people ]
    }
    var body: some View {
        List {
            ForEach(items, id: \.name) { item in
                RowView(list: item)
            }
        }
    }
}

struct RowView: View {
    @Bindable var list: MyModel
    
    var body: some View {
        if list.children.isEmpty {
            Text(list.name)
        } else {
            ParentRowView(list: list)
        }
    }
}

struct ParentRowView: View {
    @Bindable var list: MyModel
    
    var body: some View {
        DisclosureGroup(isExpanded: .constant(true)) {
            ForEach(list.children, id: \.name) { child in
                RowView(list: child)
            }
        } label: {
            Text(list.name)
        }
    }
}

struct ContentView: View {
    var body: some View {
        VStack {
            MyModelPicker()
        }
    }
}

#Preview {
    ContentView()
}

I have updated my bug report to indicate this. It seems this is an issue with @ViewBuilder being able to recursively construct views.