Crash: Exception Type: EXCBADACCESS (SIGSEGV) Exception Subtype: KERNINVALIDADDRESS Termination Reason: Namespace SIGNAL, Code 0xb In spite of the copious amounts of logging I'm performing here, I am still running into issues with this constantly. At least tell me the line of code where the crash began or something remotely related to my own code, as the watchOS logs from these crashes, are about as useful, as a miniature umbrella in monsoon. There is a vague reference to AVAudioSession Notify Thread inside the error message, but as far as the available examples I have been able to find from copious amounts of research, I am using the setActive functions correctly. Do they need to be run on the main thread only or am I missing anything else?? Please update your docs, if this isn’t the case. This ultimately and inevitably crashes the app, and due to this issue, it causes your already barely usable installer for watch OS, which has now plagued watchOS since its inception, with no improvement in site, to somehow perform even more unreliably than it already does. Building for watchOS, had quickly become an exercise in insanity, as I have to spend so much of my day, waiting for your broken watch OS compiler to fail. Out of every successful install of a watch OS update pushed from XCode, there are 5-10, and several device restarts required in between on most days. This is really bad, to put it, as nicely as I can. If you wish to pay for all the development time I’m wasting here, I will begin sending you bills, as I have reported this specific issue, dozens of times now, to never get a single response in relation to it. Either that, or I can sue you, for ***** negligence and false advertisement, but as I would much prefer not to waste anyone’s time here, as I want to keep building apps to make our world better, just fix your software please. Thank you! I don’t have any desire to make this a legal issue, but I am so tired, of having to make excuses, for your teams piss poor work. I am more than happy to work with them, if they decide to get off their butts here. But asking for logs, and never responding, or only with, could not replicate issue, is opposite of that. I could write emails saying, could not replicate issue to all my customers too, and nothing will ever get fixed, but this is not the type of person I am, and not how problems are ever resolved. Do something!!!

Please fix the GeometryReader NOW!!!! It ALWAYS crashes the entire application if the last CoreData entity is removed, or the CoreData Stack is modified somewhere else in the app and the index count changes or becomes out of range, especially from if the data was modified from inside a UIViewController, as it does not properly propagate deletes. I have no issues adding items, and then reloading the TableView were the data it being changed in, as everything propagates just fine, but as soon as I delete an item, the changes are not reflected, and the index count is not updated, and if I delete the last stored entity it crashes the app despite having the item.count > 0 protections in place, well before the ForEach loop ever hits. This issue has gone unfixed since SwiftUI first launched, and has made using a GeometryReader for anything other than a demo, an exercise in insanity. I am also getting really tired of the Geometry Reader and in general how SwiftUI, will push the wrong data to a view, even when I provide an index. The hack I have had to use to work around this, is a joke, and makes me feel like you guys plan to leave SwiftUI with a completely broken navigation stack for the foreseeable future, which is not only lazy, it will end up hurting your own company more than you can imagine. The amount of UI and Navigation Related issues that SwiftUI has created for something as simple as showing an UIAlertController on top of a SwiftUI view is mind-boggling, how you could take a simple task and turn it into a massive ordeal, that even when you get it right after messing around with it for hours, still has issues. No beginner devs are going to touch something that is this fundamentally broken, especially after they get into it and see just how broken it is, and all the documentation I can find, even the newest stuff, is completely outdated, and not even close to what the current code should look like. SwiftUI has some really cool benefits that are quickly cancelled out, by a bug around seamingly every single corner. I will remind you again, that this is a simple core date delete entity and/or the last entity, I am not asking much. Not everything in CoreData, is deleted from a Table and you gave us absolutely nothing for removing items that are not in them or a NSFetchedResultsController. This logic is so flawed I don't even know where to begin. Give us delete method or modifier that can be used across UIViewContoller, View, and that works with GeometryReader with nested ScrollViews. This should have been here out of the box, and there is no excuse you can make for why it has taken so long to fix something this simple. I have never spent this much time trying to fix your incredibly irresponsible code in my entire life!!!!!🤮🤬 Also, if you suggest adding a default entity so there is always one in there, when the last item gets deleted, I will virtually nut punch you, as this is not a fix, but an excuse for your lazy work.