Thank you very much for your detailed responses. Also, the links you provided are super helpful!

Thank you for the very detailed answer! I get the idea, and I have a few follow-up questions. And let me give a bit more context about what I'm trying to achieve. The Web Extension captures quite a bit of data from an active page and sends it to the app for background processing - doing things like parsing, storing it in a DB, some compute intensive work, REST calls, and etc. The user can see the progress and the results in the app whenever they would like but usually this will happen some time later. I don't want to distract or impact the user's browsing activity in any way, it should be "press a button and forget" kind of experience, and hence your suggestion of implementing this with launchd makes perfect sense. While I'm in the early development phase, it might be ok to just fail if the app is not running. How does this assumption make things any simpler if web ext still can't talk to the app? Or do you suggest using a socket or even an embedded web server rather than XPC? If I go with launchd approach, how will this work on iOS?

I followed this WWDC talk to add a Safari Web Extension to my app. So I went to add a new target, selected Safari Extensions, then picked Web Extensions and select my app in "Embed in Application" dropdown. Similarly, I added a new target for a XPC Service. And I tried with both high-level using NSXPCConnection and low-level using XPCSession. When I build my app, I get both targets (Web Extension and XPC Service) embedded in my app's .app file - one under Plugins, and the other under XPCServices.

My M1 Max with 64 Gb RAM just crashed because of this. Xcode 14 release, not beta, MacOS 12.6, latest update. Trying to compile this a SwiftUI view with a Table in it.

OK, if anybody ever looks for a similar question (or myself 3 years from now), here is a simple answer. Don't load your model in PersistentController initializer as this is what loads the model multiple times. Just make it static (either a let constant or a singleton) and attach it to NSPersistentContainer. Here is an example/ let modelURL = Bundle.main.url(forResource: "MyModel", withExtension: "momd")! let dataModel = NSManagedObjectModel(contentsOf: modelURL)! struct PersistenceController { let container: NSPersistentContainer init(inMemory: Bool = false, name: String = "preview") {         container = NSPersistentContainer(name: name, managedObjectModel: dataModel) // other stuff } }

Correction: the crash does NOT happen in container.loadPersistentStores call. This call completes successfully. The crash happens when a new document is opened and the document view is being constructed.  After the first document is open:  2021-12-03T11:06:05-0800 debug: in view body, context: <NSManagedObjectContext: **0x60000348dad0>** , class: , hash: **105553171372752** , coordinator: Optional(<NSPersistentStoreCoordinator: **0x6000021a8d00>)** , name: nil , objects: [] 2021-12-03T11:06:05-0800 debug: in view onAppear, context: <NSManagedObjectContext: **0x60000348dad0>** , class: , hash: **105553171372752** , coordinator: Optional(<NSPersistentStoreCoordinator: **0x6000021a8d00>)** , name: nil , objects: [] And then when I open a second document:  2021-12-03T11:08:02-0800 debug: in view body, context: <NSManagedObjectContext: **0x6000034a81a0>** , class: , hash: **105553171480992** , coordinator: Optional(<NSPersistentStoreCoordinator: **0x600002198a80>)** , name: nil , objects: [] CoreData: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'DBObject' so +entity is unable to disambiguate.  So the second view definitely gets a new context and a new coordinator, but CoreData for some reason gets confused with the same entity being loaded twice, even though they belong to two different contexts. Any idea how to disambiguate the two contexts?

Correction: the crash does NOT happen in container.loadPersistentStores call. This call completes successfully. The crash happens when a new document is opened and the document view is being constructed. After the first document is open: 2021-12-03T11:06:05-0800 debug: in view body, context: <NSManagedObjectContext: **0x60000348dad0>** , class: , hash: **105553171372752** , coordinator: Optional(<NSPersistentStoreCoordinator: **0x6000021a8d00>)** , name: nil , objects: [] 2021-12-03T11:06:05-0800 debug: in view onAppear, context: <NSManagedObjectContext: **0x60000348dad0>** , class: , hash: **105553171372752** , coordinator: Optional(<NSPersistentStoreCoordinator: **0x6000021a8d00>)** , name: nil , objects: [] And then when I open a second document: 2021-12-03T11:08:02-0800 debug: in view body, context: <NSManagedObjectContext: **0x6000034a81a0>** , class: , hash: **105553171480992** , coordinator: Optional(<NSPersistentStoreCoordinator: **0x600002198a80>)** , name: nil , objects: [] CoreData: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'DBObject' so +entity is unable to disambiguate. So the second view definitely gets a new context and a new coordinator, but CoreData for some reason gets confused with the same entity being loaded twice, even though they belong to two different contexts.

In case anyone has the same question, I couldn't make the new TableView work with dynamic data source. Then I tried constructing a bunch of TextFields dynamically in a grid. It kind of worked, but it was very sluggish when scrolling. So I ended up wrapping NSTableView in NSViewRepresentable and working directly with NSTableView APIs. Performance is great with NSTableView and NSTextField as a cell view.

@Claude31, you mentioned that it's much easier in MacOS? Do you mind sharing more details on this, please? Thanks!

I was hoping to use the new Table view in SwiftUI on Mac OS.