[quote='839309022, DTS Engineer, /thread/784248?answerId=839309022#839309022'] We suggest using native UI elements [/quote] Are you suggesting that I forgo using SwiftUI's TabView and instead use NSTabView from AppKit? I'm currently using NSTabViewController but was hoping to reduce my dependencies on AppKit and adopt SwiftUI as much as possible. We suggest using native UI elements, but you could hide the Toolbar with .toolbar(.hidden). That seems to hide the window's toolbar. I'm trying to hide the tab bar as presented by TabView on macOS, which I presume is using NSTabView. As noted above, NSTabViewController allows you to hide the tab bar and NSTabView itself offers NSTabPosition.None. However, I'm unable to configure those withTabView and thus, on macOS, I'm left with the default "Aqua-style" tab bar, which I don't want.

[quote='838899022, DTS Engineer, /thread/783804?answerId=838899022#838899022'] Are you referring to Sheet or windows? [/quote] Well, in AppKit I can present an NSViewController as a sheet via NSViewController.presentViewControllerAsSheet or I can present an NSWindow via NSWindow.beginSheet... When using NSWindow, I have easy access to NSWindow.frameAutosaveName which, if set before the NSWindow is presented as a sheet, will restore it's size. If I use NSViewController, I have to grab the window in something like viewWillAppear, but that does work. In the end, I ended up a bridged solution that does the following: Embeds the SwiftUI view that should be presented as a sheet inside an NSHostingController. Create a new NSWindow with the hosting controller as the contentViewController. Configure the NSWindow as appropriate and then present as a sheet through AppKit. It took quite awhile to get it right, but in the end the secret sauce was setting NSHostingController.sizingOptions to .intrinsicContentSize. There's still an issue with NSWindow resizing when its contentViewController is set, but I think that's been an AppKit issue for awhile. It's more reliable to just add the view to the NSWindow's contentView instead, otherwise the NSWindow resizes to the initial size of the hosting controller. But for now, it appears to be working. I suspect I'm pushing my luck a little bit because the actual view hierarchy is: NSWindow.contentViewController -> NSHostingController NSHostingController -> NSViewControllerRepresentable NSViewControllerRepresentable -> NSSplitViewController NSSplitViewItems -> SwiftUI Views VSplitView and HSplitView don't appear to remember their positions at all. NSSplitViewController does, hence the need to use it instead. But NSSplitViewController's splitViewItems were wreaking havoc with a resizable sheet. Intrinsic content size appears to have resolved that issue. Ultimately, it's three SwiftUI views hosted inside an NSSplitViewController which is presented as a resizable sheet.

Great, that's kind of what I was expecting. So a shared ViewModel like in the implementation below is the recommended way to marshal data between an NSViewController and a SwiftUI View? import AppKit import SwiftUI final class ViewModel: ObservableObject { @Published var details: String = "" } struct DetailsView: View { @ObservedObject var viewModel: ViewModel var body: some View { Text(viewModel.details) } } final class ViewController: NSViewController { private let viewModel: ViewModel init() { self.viewModel = ViewModel() super.init(nibName: nil, bundle: nil) } override func viewDidLoad() { let detailsView = DetailsView(viewModel: viewModel) view.addSubview(NSHostingView(rootView:detailsView)) } func updateDetails(_ details: String) { viewModel.details = details } }

Same problem here. Updated to macOS 15.1 today and then downloaded Xcode 16.1 (16B40). On launch, Xcode attempted to download the predictive code model but failed. Also fails when download is invoked from Xcode - Settings - Downloads. This is the first attempt at downloading Xcode's predictive code model. Prior to today, laptop was running macOS 14. The operation couldn’t be completed. (ModelCatalog.CatalogErrors.AssetErrors error 1.) Domain: ModelCatalog.CatalogErrors.AssetErrors Code: 1 User Info: { DVTErrorCreationDateKey = "2024-10-28 20:15:42 +0000"; } -- Failed to find asset: com.apple.fm.code.generate_small_v1.tokenizer - no asset Domain: ModelCatalog.CatalogErrors.AssetErrors Code: 1 -- System Information macOS Version 15.1 (Build 24B83) Xcode 16.1 (23503) (Build 16B40) Timestamp: 2024-10-28T16:15:42-04:00

Updated (See reply below.)

Follow-up 2: Oh, interesting! If you create a new XPC target in Xcode and opt for the "libXML" option, then the template that is generated shows how to pair xpc_session with xpc_listener. Kudos to whoever at Apple was responsible for that...

Looks like it's as simple as attached a binder to columnVisibility in the NavigationStackView initializer and setting an appropriate column visibility value as needed.

Sure thing, though as a perfect example of what I'm referring to, I actually can't log into Feedback Assistant within a virtual machine. Feedback Assistant's login screen simply reports "An error occurred during authentication." when I enter my Apple Developer credentials. I can, of course, log into Feedback Assistant from the host macOS instance, but not from within the guest instance. At the moment, my host is running Monterey while my guest is running Ventura. I'd like to spend more time testing Ventura and building software within it, but without access to iCloud or my developer account, it makes that goal almost impossible.

This question comes up so frequently that it would be extremely appreciated if someone on the SwiftUI team or a DTS representative could chime in on this. The vast majority of sample code and documentation assumes a view model can be created without any parameters to its initializer, which is not always the case. And in the Fruta example app a single Model is used for the entire application, which really isn't realistic for larger scale applications. I've resorted to the following design pattern but I remain unsure if this is considered a "correct" way to initialize an @StateObject property: struct ParentView: View { var body: some View { ChildView(viewModel: ChildViewModel(someValue: "foo")) } } class ChildViewModel: ObservableObject { init(someValue: Any) { } } struct ChildView: View { @StateObject var viewModel: ChildViewModel } This pattern appears to work correctly and doesn't require the small "hack" of using the underscore to initialize the @StateObject, which appears to be discouraged based on my reading of the documentation: StateObject.init(wrappedValue:) // You don’t call this initializer directly. Instead, declare a property with the  // @StateObject attribute in a View, App, or Scene, and provide an initial value: struct MyView: View { @StateObject var model = DataModel() }