Is there a way to pause or disable syncing via NSPersistentCloudKitContainer at runtime? I want to give my users the option to enable or disable syncing, but there doesn't seem to be a good way to do it. I tried reloading the persistent stores and setting the store description's cloudKitContainerOptions to nil, but if I do that after first initialization, I get an error:error: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only modeAnyone know of another way to do this?I submitted a request via Feedback Assistant for a flag to enable or disable syncing (FB6156182). I know the user could theoretically go into the Settings app and enable or disable iCloud access for the app as a whole, but that's not very discoverable, and disables all iCloud access. I'm looking for something a little more fine-grained (limited to the NSPersistentCloudKitContainer) and that I could control in my app's UI.

I'm running into trouble setting up sync using NSPersistentCloudKitContainer on an existing app. The app doesn't seem to sync data that was added to Core Data prior the app's iOS 13 update. For instance:1. I install an existing, pre-iOS 13, version of the app and create several records that are stored in Core Data.2. Over that existing install, I install the updated version that uses NSPersistentCloudKitContainer and create some additional new records.3. I install the same new version on a second device.Results: Records created in step 1 don't appear on the second device, but records created in step 2 do.Is there a step I'm missing in order to get existing data to sync? I'm wondering if this has something to do with the persistent history token, but I'm unsure how to tell NSPersistentCloudKitContainer it should "start over" on first launch.

I’m working an update for an app that will increase the minimum iOS version that the app supports, and I’m trying to determine whether users on an older version of iOS will still automatically receive updates for the last supported version. For instance, suppose I released version 1.8 of my app last week, which supported iOS 12 and above. This week, I release version 2.0, which increases the minimum iOS version to 13. Would a user running iOS 12 who hadn’t yet installed version 1.8 (which was the last to support iOS 12) still see version 1.8 in the App Store updates area, and receive the update automatically if they have automatic updates enabled? (I know they wouldn’t see or receive 2.0, since that requires a newer version of iOS.) TLDR: Do users on an older version of iOS still receive updates as far as the highest app version that supports their version of iOS, without having to go manually download them?

After installing Xcode 14 beta 3, the iOS 15 simulators in my Xcode 13 install seem to have vanished. Adding new ones in the Devices and Simulators window does nothing. Deleting both Xcode installs and installing a fresh copy of Xcode 13.4.1 also didn't help. Seems like I'm not alone: https://twitter.com/mattkiazyk/status/1544761694341451776 https://twitter.com/bourvill/status/1544797153104625664 Anybody have ideas for how to fix? Feedback filed: FB10570079

I want to use the original_application_version value from the app receipt to grandfather some features for users who are first-time users vs existing users. In the Receipt Validation Programming Guide, the field's notes are as follows: This corresponds to the value of CFBundleVersion (in iOS) or CFBundleShortVersionString (in macOS) in the Info.plist file when the purchase was originally made. In the sandbox environment, the value of this field is always “1.0”. I'm unsure which value to expect in Mac Catalyst, since it's a UIKit (and thus iOS)-based app being distributed through the Mac App Store and run on a Mac. My instinct is that the store is determinative, and thus to expect the macOS CFBundleShortVersionString on the Mac. Unfortunately, since the value is always "1.0" in the sandbox (including TestFlight) I don't have a good way to test this. Does anyone have any real-world experience that can shed light on what format I can expect?

I'm starting to work on updating my code for Swift 6. I have a number of pieces of code that look like this: private func updateModel() async throws { try await context.perform { [weak self] in // do some work } } After turning on strict concurrency checking, I get warnings on blocks like that saying "Sending 'self.context' risks causing data races; this is an error in the Swift 6 language mode." What's the best way for me to update this Core Data code to work with Swift 6?

I'm trying to debug a couple of crash reports for a Mac Catalyst app and seem to be unable to symbolicate my crash reports. In the Xcode Organizer, I see unsymbolicated lines for my app, despite having the original archive for the build in question. A search for the relevant dSYM (using the process from https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report#Locate-a-dSYM-Using-Spotlight) yields no results. Unlike iOS builds, the "Download dSYMs" button isn't present in the organizer, nor is the option to download dSYMs from App Store Connect. I assume this is because macOS apps don't use bitcode. The app's Debug Information Format is set to DWARF with dSYM File. Has anyone else run into this issue? Any ideas about how I can symbolicate the crash logs?

As far as I can tell, there’s no equivalent to Core Data’s NSFetchedResultsController in SwiftData. It would be very helpful to have a way to respond to sets of changes in a ModelContext outside of a SwiftUI view. For instance, this is very helpful when using a Model-View-ViewModel architecture. The @Query property wrapper is great for use in a SwiftUI view, but sometimes it’s helpful to process data outside of the view itself. The fetch() method on ModelContext is helpful for one-time operations, but as far as I can't tell it doesn't address receiving changes on an ongoing basis. Am I missing some equivalent for this use case? Also filed as feedback FB12288916

I have an iOS app that also has a Mac Catalyst version that I distribute on the Mac App Store. I upload builds to App Store Connect and use the "Manage version and build number" setting introduced in the past couple of years. This always works without a problem for the iOS version of the app. However, on the Mac, I often get a validation error like this: This bundle is invalid. The value for key CBundleVersion [2958] in the Info.plist file must contain a higher version than that of the previously uploaded version [2959]. Please find more information about CFBundleVersion at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion (ID: 44cc3c93-a563-45bd-8e10-884444207eae) This is all without making any changes to the code or info plist. The exact same code will build, archive, and upload with no problems whatsoever. I often end up having to manually update the bundle version in order to get an upload to succeed. Once I do, both the iOS and Mac versions will upload and validate successfully, but the problem inevitably returns in future releases. All in all, it seems to defeat the purpose of the Xcode automatic build management feature. Am I missing a step somewhere? Why would this happen with the Mac build but not iOS?