I just wanted to add a message of support here for this feature request. I've also filed a feedback report.

You say "Services are not features of the app" but then spend the next four lines describing how your app allows people to buy digital services. This is a little confusing.

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.

Maybe try something like this. struct AView: View { @ObservedObject var viewModel: MyAppViewModel ... public var body: some View { ... ForEach(...) { ... OtherView(vm: viewModel) } } } struct OtherView: View { @ObservedObject var vm: MyAppViewModel var body: some View { ... } } Your ViewModel should be a class so when you pass it around you are just passing the same instance of the class around rather than creating new instance of it each time.

I would do it in main app struct like this and pass it into your main view. import SwiftUI @main struct MyApp: App { private let viewModel = MyAppViewModel() var body: some Scene { WindowGroup { MyAppView(viewModel: viewModel) } } }

Thank you both @@NickPolychronakis and @kennedycraig as I really struggled to get figure this out on my own. I just wanted to add for anyone else that is reading that the code above won't actually work if starting with an empty database. If anyone wants or needs to see a complete project to get this working for them I modified the standard Xcode Core Data template app to work with a picker. https://github.com/dah/CoreDataPickerExample

Hi I'm having the same issue but I managed to have solved it. I've set the window's minSize variable like this in AppDelegate.swift: window = NSWindow( contentRect: NSRect(x: 0, y: 0, width: 916, height: 648), styleMask: [.titled, .closable, .miniaturizable, .resizable, .fullSizeContentView], backing: .buffered, defer: false) window.center() window.aspectRatio = NSSize(width: 229, height: 162) window.minSize = NSSize(width: 916, height: 648) window.setFrameAutosaveName("Main Window") window.contentView = NSHostingView(rootView: contentView) window.makeKeyAndOrderFront(nil)That prevents the window from opening with a smaller size, but it doesn't prevent the user from resizing the window smaller than that.