Is it correct that there is no way in SwiftUI 2.0 to coordinate dragGestures between custom views and within those custom views embedded views like ScrollView or List? I could not find any way to get hold of the gestures of the built in views (e.g. List) to combine them with a dragGestures of my custom view. I would need gesture composition to be able to provide a good UX in situations like, e.g: I implemented a custom bottomSheet view (like in maps) and within this bottomSheet I am using a List view. When the user drags within the half open bottomSheet, the gesture should, e.g. Move the bottomSheet to the full open position (like in maps) As soon as the bottomSheet is in the full open state, the List view should be scrolled up On the way „down“ vice versa: when the user drags down, The list should scroll down As soon as the list is completely scrolled down, the bottomSheet should start moving down I do not see a way to implement such behaviour without access to the drag gestures of the SwiftUI built-in List or ScrollView.  Or do I miss something here?

I have expanded my CoreData model quite a few times, including renaming entities, properties (and as far as I remember relationships). I am still working in the (CloudKit) development environment, only. Now I am getting errors each time I start the app (one line out of many shown): CoreData: debug: CoreData+CloudKit: -PFCloudKitMetadataModelMigrator calculateMigrationStepsWithConnection:error:(404): Skipping migration for 'ANSCKDATABASEMETADATA' because it already has a column named 'ZLASTFETCHDATE' The app is working as expected, it seems this error has no effect on correct CoreData+CloudKit execution. But I want to get rid of this error warning before I deploy to production for TestFlight or expand CoreData further. To have a clean CD+CK base I can start migrations from in future. Can I just reset CD (or CoreData's model) to make CD accept the current model as the base model without any migrations attached to it? An Apple Engineer suggested here - https://developer.apple.com/forums/thread/47637?answerId=146890022#146890022 to use destroyPersistentStore(at:ofType:options:), but one should be careful to call this method on NSPersistantCoodinator with the same options as when the store has been added. Since the store is created by NSPersistentCloudKitContainer I do not know the options used. My questions are: Is the above error related to a failed automatic migration? How serious is this error/warning? Can I get rid of this error by destroying the store? Once only? Then going back to my current NSPersistentCloudKitContainer creation code. Is there any other suggested way of going forward? Would a future lightweight migrations solve this error, too? Thank you in advance for your help!

At min 21 into the video Bring Core Data concurrency to Swift and SwiftUI, Scott entered @State private var selectedSort = SelectedSort() Why is he not using @StateObject? I would have expected @StateObject is the way to go here as we are creating the SelectedSort() within the View. Because we want to tell SwiftUI to reserve storage for this property and keep it across view updates. I would expect that using @State would mean that our SelectedSort() is re-created whenever the View is re-created, with the effect that sorting reverts to default. What is the correct way to do it and why?

Whenever switching the AVSpeechSynthesizer voice to a (different) German voice the app waits/hangs for a few seconds (depending on device) before speech output starts. Looking into the console output I see that the German language rules data is five to nine times large than e.g. English or Italian: 10:55:16.137820+0200 ... #MobileAsset listing ...'[Available: true, Language: de-DE]' ... 10:55:07.636488+0200 ... Loading on disk rule data: 4392529 10:55:10.818661+0200 ... processing rules: 459, NS: 28669 10:55:10.840711+0200 ... Creating playback session rate: 22050, channels 1 showing the loading on disk rules took about 3.2 secs in this German voice case. If I look into loading of an English or Italian voice those load times are much shorter: 10:55:16.137820+0200 ... #MobileAsset listing ...'[Available: true, Language: en-US]' ... 10:55:16.148741+0200 ... Loading on disk rule data: 862210 10:55:16.407063+0200 ... processing rules: 12192, NS: 1611 10:55:16.428606+0200 ... Creating playback session rate: 22050, channels 1 10:55:16.137820+0200 ... #MobileAsset listing ...'[Available: true, Language: it-IT]' ... 10:54:50.816431+0200 ... Loading on disk rule data: 536565 10:54:51.493129+0200 ... processing rules: 2567, NS: 4149 10:54:51.514703+0200 ... Creating playback session rate: 22050, channels 1 showing load times of 0.25 and 0.7 secs, only! Interestingly, if I do a small test app which has exactly the same setup and usage of AVSpeechSynthesizer as in my main app, I can NOT reproduce those lengthy load times, respectively lags/waits until speech output starts following a voice change to a (different) German voice. This is my code for calling AVSpeechSynthesizer.speak(_): func speak(_ textToSpeak: String) { appState.isPrePause = true // Detect language of incoming text to speak. var lang = "" if let dominantLanguage = NLLanguageRecognizer.dominantLanguage(for: textToSpeak) { lang = dominantLanguage.rawValue } else { lang = "en" } // Select a voice based on the detected lanuage. let voice = AVSpeechSynthesisVoice(language: lang) if voice == nil { print("WARNING: no voice for the current language \(lang). Falling back to default voice.") } let utterance = AVSpeechUtterance(string: textToSpeak) utterance.voice = voice utterance.preUtteranceDelay = appState.preUtteranceDelay utterance.postUtteranceDelay = appState.postUtteranceDelay avSpeechSynth.speak(utterance) } The described lag is happening between calling avSpeechSynth.speak(utterance) and the Synthesizer Delegate callback "didStart". I have files a feedback report to Apple (FB11380447) about three weeks ago with regular updates afterwards. Has anybody experienced something like this? Any suggestions on where to dig further?

NavigationStackView with .searchable modifier is working as expected. struct NavStackListSearchView: View { @State private var items = ["Item1", "Item2", "Item3", "Item4", "Item5"] @State private var selectedItems: Set<String> = [] @State private var searchText: String = "" var filteredItems: [String] { if searchText.isEmpty { return items } else { return items.filter { $0.contains(searchText) } } } var body: some View { NavigationStack { List(selection: $selectedItems) { ForEach(filteredItems, id: \.self) { item in NavigationLink(item) { Text(item).font(.title3) } } } } .searchable(text: $searchText) .onChange(of: searchText) { _ in selectedItems = [] } } } But NavigationSplitView with .searchable modifier is crashing: struct NavSplitListSearchView: View { @State private var items = ["Item1", "Item2", "Item3", "Item4", "Item5"] @State private var selectedItems: Set<String> = [] @State private var searchText: String = "" var filteredItems: [String] { if searchText.isEmpty { return items } else { return items.filter { $0.contains(searchText) } } } var body: some View { NavigationSplitView { List(selection: $selectedItems) { ForEach(filteredItems, id: \.self) { item in Text(item) } } } detail: { if selectedItems.isEmpty { Text("Pick an item") } else { Text("\(selectedItems.first ?? "--no item--")") } } .searchable(text: $searchText) .onChange(of: searchText) { _ in selectedItems = [] } } } To reproduce the crash in NavSplitView: launch the app click on "Item3" go back (if in compact mode) search for "3" click on only item shown, that is "Item3" --> crash Seems to be an issue with the index into the List/ForEach? But I see no way of influencing/double checking on that index. A change of filteredItems based on searchText should be recognised by SwiftUI as it is based on @State property items. What do I miss? How can I solve this issue? Target iOS 16.2, Xcode 14.2

PDFKit's PDFPage.characterBounds(at: Int) is returning incorrect coordinates with iOS 17 beta 5 / Xcode 15 beta 6. Worked fine iOS 16 and earlier. It breaks critical functionality that my app relies on. I have filed feedback (FB12918701).

I have an Xcode project under git version control (github). I recently had changed the github user name. Xcode detects the name change and shows it correctly under Settings/accounts. Push and pull still work as expected. When I tried to configure Xcode Cloud I got an error message similar to '...Xcode Cloud could not connect with your source control provider...' during initial setup procedure. [1] The solution for me has been to edit the git config file, updating the URL for [remote "origin"] to the new path reflecting the new git user name. I would have expected that Xcode would have updated this config file when recognising the github user name change. [1] A exact German language error has been: "Die Verbindung von Xcode Cloud mit Ihrem Quellcodeverwaltungsanbieter konnte nicht erstellt werden. Versuchen Sie den Einrichtungsablauf erneut, um Xcode Cloud Zugriff auf Ihren Quellcode zu gewähren. Weiter in Xcode"

PDFKit PDFPage.characterBounds(at: Int) is returning incorrect coordinates with iOS 18 beta 4 and later / Xcode 16 beta 4. It worked fine in iOS 17 and earlier (after showing the same issue during the early iOS 17 beta cycle) It breaks critical functionality that my app relies on. I have filed feedback (FB14843671). So far no changes in the latest betas. iOS release date is approaching fast! Anybody having the same issue? Any workaround available?

Bug in iOS 18 beta? .onAppear of a NavSplitView-DetailView is called repeatedly after dismissing the view. The app gets unresponsive and can only be killed and cold-restartet. What happens: I update a Binding property in .onAppear of a NavigationSplitView-DetailView. Whenever I leave the DetailView going back to the ListView (the NavSplitView’s first column), the DetailView's .onAppear get’s triggered in an endless loop. This blocks the main thread and freezes the app. This behaviour is only appearing in iOS 18 betas (simulators and devices) and not on iOS 17.x releases. If I remove the code updating the Binding, the .onAppear loop does not happen. Another way of triggering the same unexpected behaviour is by updating an OberservedObject appState.shared singleton, e.g. by a timer. Has anybody come across this type of behaviour? Is this a know change of iOS 18 behaviour or a bug even?