Given that you'd move the Core Data store to a group container, I'd assume that the store will be shared across different processes, such as your main app and its extension (a widget, for example). In that case, I'd like to start with pointing you the following threads: Core Data Light Migration Crash When Widget is Installed (Error 134100). CoreData error=134100 Failed to open the store. These threads made it clear that: After a user installed your new version app, depending on what extension you have, the app and extension can open and migrate the store simultaneously, and so you will need to implement a mechanism to make sure that the store is only migrated once. Consider having your main app in charge of the the synchronization, as discussed in Avoid synchronizing a store with multiple persistent containers. Thank you, this is very helpful. At the moment, my app does not have any widgets or extensions, but adding them is one of the reasons I want to move the store into an app group container. From what you’ve described, it sounds like the migration window is where things can become problematic once multiple processes are involved. Even if I do not have extensions today, existing users could upgrade to a version that introduces them, which means I still need to think about co-ordination early. My initial plan was to introduce widgets and extensions in the same update that performs the store relocation and schema migration. However, given the potential for concurrent access during migration, I am reconsidering that approach. I am now leaning towards introducing them in a later phase, for example: Phase 1: store relocation and schema migration Phase 2: CloudKit adoption Phase 3: widgets and extensions Does that sequencing sound reasonable to you, or would you still consider it safe to introduce widgets and extensions alongside the migration? Regarding your suggested flow: Combining relocation and migration is fine to me. I'd consider the following flow in your app's launch session: Load the store with your new version model to your Core Data stack, which kicks off the migration. After the migration is successfully done, copy the migrated store to your target folder using replacePersistentStore(at:destinationOptions:withPersistentStoreFrom:sourceOptions:type:). Remove the orginal store using destroyPersistentStore(at:type:options:). Combining relocation and migration in a single launch makes sense to me. However, I am slightly concerned about deleting the original store immediately. In case of issues with the new version, or if a user rolls back to a previous version of the app, keeping the original store temporarily would provide a safer fallback. Would you recommend deferring removal of the original store until a later point, or is immediate cleanup generally considered safe in practice?

I have some information. I downloaded Xcode 26.3 Release Candidate (17C519) from the Apple Developer website. I used the VirtualBuddy app and installed macOS Tahoe 26.3. I then opened the Xcode project and configured the StoreKit Configuration file (synchronised with App Store Connect), setting the subscription renewal rate to Any Renewal Every 10 Seconds. I ran the app, made a subscription purchase and observed that my in-app purchase handling code successfully completed the transaction. I also logged Transaction.updates and Product.SubscriptionInfo.Status.updates and everything worked as expected. However, I do not wish to upgrade to macOS Tahoe just yet.

Thanks @DTS Engineer, I have already read that documentation. You advised that I should enable all the settings. However, I noticed that for Memory Tag Pure Data, the description states that “it may incur a performance overhead”. I am therefore inclined not to enable it. Regarding Enable Soft Mode for Memory Tagging, the description states that “memory tagging faults will not crash and will be logged instead”. I am inclined to leave this disabled, as I would prefer the application to crash so that I can receive a crash report and potentially fix the issue. I am not entirely sure what is meant by logging in this context, would this appear in the Xcode console when running in Debug mode? As you are knowledgeable about AppKit and Mac computers, may I ask if you would mind looking at my other post about StoreKit 2? I am at my wits’ end, as I would like to ship the Cocoa app using the API but cannot because it is not behaving as expected. I am tempted to submit a code-level support request for this.

Yes, it refreshes Transaction.updates and Product.SubscriptionInfo.Status.updates. I added the following method to InAppPurchaseManager: func refresh() { Task { for await result in Transaction.currentEntitlements { print("\nReceived current entitlements update...") try? await result.payloadValue.finish() } } } And called it in applicationWillBecomeActive(_:): func applicationWillBecomeActive(_ notification: Notification) { InAppPurchaseManager.shared.refresh() }

It sounds like you tested it on iOS. I understand that some developers refresh Transaction.currentEntitlements when the iOS app switches to the foreground. Yes, I do handle Transaction.unfinished and it is not related to my issue. Have you seen this post by @saxmanbob? He had a similar issue to mine, but he resolved it due to some “Objective-C machinery”. I don’t use Objective-C in my app, although it may exist within some Swift packages. Please try the following and let me know if you get the same result. Download the CotEditor Xcode project, copy and paste the InAppPurchaseManager code somewhere appropriate and launch it in applicationDidFinishLaunching(_:). Locate the CotEditor.storekit file and change the Subscription Renewal Rate to Any Renewal Every 10 Seconds or Any Renewal Every 2 Seconds. Run the app and observe the console. You will see that it does not behave as expected. You could also try this in a fresh AppKit Xcode project. You don’t need to build the UI and you will see that it works perfectly.

@saxmanbob I am experiencing the same problems in my AppKit app. I have made a post about it here. Could you please tell me a bit more about how you solved it? I’m desperate to fix it in my app. I don’t use Objective-C in my app, as it is all written in Swift, but I imagine there may be some in the Swift packages.

My app is a Mac app that uses the AppKit framework. It is not a SwiftUI app, nor is it an iOS app. It uses SwiftUI for some views. The sample project code is similar to my code snippet but is built using the SwiftUI design pattern. I want Transaction.updates and Product.SubscriptionInfo.Status.updates to work, but they are not detecting the changes I make when I make purchases, nor are they detecting purchases when using the Xcode Transaction Manager. Also, I use subscriptionStatusTask(for:priority:action:) modifier where I use ProductView and it doesn't work. It is supposed to react in real time. It works if I reload the view by switching to another view and then back. I believe it is less to do with the code and is something else. Maybe the Xcode project file settings is messed up or I am missing something. I tried restarting the Mac and clearing the derived data. Likewise, as I mentioned, it works perfectly in a fresh Xcode project with a minimal setup, but it doesn’t work in my project. Why?

Sorry, how would using the @Observable macro help in this case? As I mentioned in my post, the InAppPurchaseManager works perfectly in a fresh Xcode project with a minimal setup.

I experienced the same problem on macOS Sequoia 15.7.3 (24G419). I did it this way: pickerViewController.view.setFrameSize(...)

Sadly, this is still present in Xcode Version 16.3 (16E140).

I have filed a feedback report, FB16341774. I tried your steps and it works but the errors come back after a little while, whilst working on the project.

Updating the macOS to 15.2 (24C101) fixes the problem. It works on first try.

I have the same problem as I am using an M4 Pro Mac. It worked when I first got the computer but after a little while, it stopped working. I've just updated to Xcode Version 16.2 (16C5032a) on macOS 15.1.1 (24B2091) and it is still not working.

I see. I intend to integrate my app development workflow with Xcode Cloud and/or with a third-party CI/CD. I have not done it yet but would it work straightaway or do I need to do something about it in advance?

I had these problem when I was using Xcode Version 15.3 (15E204a). It turns out that they have fixed it but then Apple has apparently changed something in their backend. There's an opened issue about the new problems, Malformed Framework response from App Store Connect. The suggestion for the meantime is to use Xcode Version 15.2 (15C500b).