Well from a design perspective I like to use @State variables in views just for dealing with state in the view. What you're doing would seem to classify as part of the "business logic" of your app so I would offload that logic away from your view to your "model" or "view model." Look up MVVM if you don't know what these are.
Anyway if you were to take an MVVM approach your code might look like:
struct ContentView: View {
@ObservedObject var viewModel: MyViewModel
var body: some View {
Button(action: {
viewModel.readApk()
}) {
Text("Read Apk")
}
.padding()
Button(action: {
viewModel.signApk()
}) {
Text("Sign Apk")
}
.padding()
}
}
With this approach processString, usingDirString, and returnDirString are all abstracted away from your view. By keeping your view code and your business logic separate it makes it easier to deal with each of them in a more isolated and clear manner.