Today I have been testing something unrelated in my SpeechApp on the iOS 16.4 Simulator with Xcode 14.2 (and later 14.3) and to my surprise, the change of German languages from one utterance to the next worked as fast as it should be, no more 3+ secs delay! Cool, has Apple finally solved the bug?! I moved to a device. But no: on device with iOS 16.4.1 installed, the same issue as always, the delays between utterances with different German voices are back. Reinstalled the app on the device, re-downloaded the German voices used. But no luck. This is the console output of the app running on device. The delay happens after the first "[AXTTSCommon] Invalid rule:" appears in the console. Speech Synthesizer - Current utterance voice: Optional("Viktor (Enhanced)") | language: Optional("de-DE") 2023-04-09 13:04:06.172618+0200 SpeechApp[914:31631] [AXTTSCommon] Invalid rule: <----- DELAY HAPPENS AFTER THIS LINE 2023-04-09 13:04:10.052499+0200 SpeechApp[914:31631] [AXTTSCommon] Invalid rule: 2023-04-09 13:04:10.053138+0200 SpeechApp[914:31631] [AXTTSCommon] Invalid rule: 2023-04-09 13:04:10.055567+0200 SpeechApp[914:31631] [AXTTSCommon] Invalid rule: 2023-04-09 13:04:10.113567+0200 SpeechApp[914:31164] [audio] --- SpeechSynthesizer Delegate - did START speaking utterance. The console output of the Simulator. It shows only one line with "[AXTTSCommon] Invalid rule:" and moves over it quickly, without any delay: Speech Synthesizer - Current utterance voice: Optional("Viktor (Enhanced)") | language: Optional("de-DE") 2023-04-09 13:01:59.764986+0200 SpeechApp[7145:111421] [AXTTSCommon] Invalid rule: 2023-04-09 13:01:59.778640+0200 SpeechApp[7145:108690] [audio] --- SpeechSynthesizer Delegate - did START speaking utterance. Can anybody confirm that German voices work correctly on Simulator while switching german voices between utterances, while still showing unacceptable delays between utterances on device?

I believe this is a SwiftUI crashing bug. I filed a Feedback with Apple (FB12059008).

@Steepz I found a solution. Use the scene(_, willConnect, options) Scene Delegate callback and extract the share metadata like so:     func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {         guard let cloudKitShareMetadata = connectionOptions.cloudKitShareMetadata else { return }         // Do something with the cloudKitShareMetadata...     }

@Steepz Have you found a solution? I have the same issue and can not find a way around it. Even the latest Apple Sample Code behaves like that, i.e. not triggering userDidAcceptCloudKitShareWith in SceneDelegate on the apps first/cold launch. On subsequent launches the delegate method gets triggered!?(https://developer.apple.com/documentation/coredata/sharing_core_data_objects_between_icloud_users)

@computerdude Same here. What exactly did you do wrong in the first place, and how did you fix the issue?

@paulo_andrade Same question here. Have you found an answer, yet?

Hi @georgbachmann, I have not found a solution, yet. Apple has been requesting additional infos two weeks ago (sysdiagnose file with with a Siri logging profile installed). No further comms from Apple so far. It would be really(!) helpful if you could file a Feedback regarding your (same) issue referencing my Feedback ID (FB11380447). Thanks! Regarding the logs: I connected the device to the Mac running Xcode and then selected the device in Console. I suggest we keep each other updated on the issue here in this forum. Best, Klaus.

FYI, I have not found a solution, I guess there is no way do what I tried to do in SwiftUI 2/3. I instead use the (new) UISheetPresentationController (implemented via UIViewControllerRepresentable). Works as expected.

Conclusions: After moving "back in time" by checking out a very early build of my app with an early version of the managed object model (database description) installing that app version on the simulator moving forward to the latest build the console reported a successful automatic migration of the CoreData database. After that success, the "Skipping migration" error showed up again. I filed a feedback report to Apple and got the answer: this "skipping migration error" console output is normal/expected behaviour. Case closed for me.

After upgrading to Xcode 12.5 and launching the app for the first time in the Simulator (not logged into iCloud) the app loads some data into the empty CoreData database no migration errors show up After restarting the app for a second launch the "skipping migration" errors are back in the log.

Additional info to my questions above: even if I delete the app from the test device reset the Development Environment in the CloudKit dashboard for my apps container then reinstall the app out of Xcode the same "skipping migration" error shows up in the console. This does not make sense to me. Why after all CoreData DBs on test device(s) have been cleared and newly compiled code has been installed on device. Shouldn't Xcode use the current NSManagedObjectModel as the new zero generation model, and thus not need any migration!? What do I miss here? Or is this a CoreData bug? P.S. the log shows these lines: Skipping migration for 'ANSCKMETADATAENTRY' because it already has a column named 'ZDATEVALUE' Skipping migration for 'ANSCKRECORDMETADATA' because it already has a column named 'ZNEEDSUPLOAD' Skipping migration for 'ANSCKRECORDMETADATA' because it already has a column named 'ZNEEDSLOCALDELETE' Skipping migration for 'ANSCKRECORDMETADATA' because it already has a column named 'ZNEEDSCLOUDDELETE' Skipping migration for 'ANSCKRECORDMETADATA' because it already has a column named 'ZLASTEXPORTEDTRANSACTIONNUMBER' Skipping migration for 'ANSCKRECORDMETADATA' because it already has a column named 'ZPENDINGEXPORTTRANSACTIONNUMBER' Skipping migration for 'ANSCKRECORDMETADATA' because it already has a column named 'ZPENDINGEXPORTCHANGETYPENUMBER' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZLASTFETCHDATE' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZSUPPORTSFETCHCHANGES' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZSUPPORTSATOMICCHANGES' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZSUPPORTSRECORDSHARING' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZNEEDSIMPORT' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZNEEDSRECOVERYFROMZONEDELETE' Skipping migration for 'ANSCKRECORDZONEMETADATA' because it already has a column named 'ZNEEDSRECOVERYFROMUSERPURGE'