Attempting to use NSBatchInsertRequest initialized with an entity name and a managedObjectHandler like so: let insertRequest = NSBatchInsertRequest(entityName: "Application") { (object: NSManagedObject) in     object.setValue("My Application", forKey: "name")     return true } insertRequest.resultType = .objectIDs does not do anything on macOS (12.5) for me. The execution of the request is done like this: do {     let viewContext = library.persistentContainer.viewContext     let insertResult = try viewContext.execute(insertRequest) as? NSBatchInsertResult     if let objectIDs = insertResult?.result as? [NSManagedObjectID] {         NSManagedObjectContext.mergeChanges(fromRemoteContextSave: [NSInsertedObjectsKey: objectIDs], into: [viewContext])     } } catch let error { // handle err } The problem is that objectIDs is always empty and thus nothing gets inserted. However, when I switch to init'ing an NSBatchInsertRequest using an objects array, everything works fine. Despite having Core Data SQL logging enabled and searching inside the Console, no errors are thrown or any indicator as to why the insertion has failed. Is it possible that this method is not really implemented on macOS and only works on other platforms such as iOS? Note: I'm aware that performance wise a batch insertion of objects done on the main context is not ideal.

I have an app with the following simple architecture: Main App: A regular macOS app bundle with UI that allows users to customize settings of the app Helper: Another macOS app bundle with no UI (LSUIElement=1 in Info.plist) that is packaged inside the main app in the LoginItems directory doing the core tasks of the app in the background My requirements are: Distribution via the MAS (=sandbox enabled for both targets) Both apps should be able to communicate via XPC The main app should be closable by the user at any time, should not keep running after being closed, whereas the helper app should as it performs actions for which it needs to be kept running in the background Launch-on-login of the helper app should not (and according to 2.4.5 (iii) of the ASRG must not) happen automatically w/o user consent and therefore I assume should always be a checkbox optional to the user For sharing settings changed by the user in the main app with the helper too, I've added the Application Group capability to both targets to allow usage of a common user defaults suite. While that works fine, there's the requirement that from within the main app I'd also need to request information and call a method from the background process (bidirectional communication) which is where I'm currently stuck. I understand that an XPC Service (.xpc) would not be suitable for the helper here because it is automatically terminated when the parent app dies and may also not be suitable for my use cases as the helper needs to be able to request Screen Capture permissions from the user and I doubt this is possible for XPC bundles. I also understand that an XPC service which utilizes a mach-service XPC listener will only work in a sandboxed environment through the use of Service Management's SMLoginItemSetEnabled() API. My main issue here is that the mandatory requirement to leave the option to launch the helper on login open to the user conflicts with the requirement of being able to communicate with the helper via XPC any time the main app is open, regardless of user choices. If there wasn't the requirement to sandbox both apps, I would solve this issue with a launchd user agent that is kept alive but only runs at load if the user checked the launch-on-login box in the Settings of the main app. With sandbox enabled though, I'm currently launching the helper app manually if launch-on-login is disabled and let the Service Management API handle the lifecycle if it is enabled. For the first case, I haven't been able to establish an XPC connection w/o calling SMLoginItemSetEnabled() and I assume that is by design. Is there something obvious I've missed here as I kinda feel like this is a typical app setup many other 3rd party devs are having as well?