We're experiencing the same issue with the release candidate. Seems that Xcode 15 is not able to install our dev certificate to the device.
So there is no way of actually trusting it.
Edit:
Not quite show how I fixed it. But by some combination of deleting derived data, restarting my phone, and reinstalling Xcode 15 release candidate it now work.
Brent-Envoy
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
can confirm this happens on iOS 17.2 as well.
It seems like the issue is the lists built-in selection and swipe gestures interfere with any added custom gestures.
I have tried using high priority gestures, simultaneous gestures and just regular gestures and none of them seem to allow BOTH the list and the custom gestures to work simultaneously.
I have noticed this issue with quite a few of the UIKit backed swiftui features such as context menus, Lists, Forms, etc...
Maybe it's time that SwiftUI started to get native SwiftUI implementations of these features.
Theres just one caveat to all of this.
With swift observation, all of those ObservableObject issues go away.
The observation framework is smart enough to only update the views that are actually observing a value (just like @State does). Rather than every view (and all of its children) that has an @ObservedObject/@EnvironmentObject/@StateObject in it.
So for projects supporting iOS 17 and newer, MVVM is probably valid.
Also Pointfree back ported Observation to iOS 13. So theoretically, you can use all of this new observation stuff right now.
The tools available for us to debug SwiftUI issues are astonishingly bad. Obfuscating stack traces like this makes it even worse. I really hope more is coming in the pipeline for these issues. Or swiftUI adoption will continue to be slow.
Just replying here to get some more traffic on this.
It's kind of ridiculous that we still don't have this feature.
Anyone have a working swift solution for this?
I tried calling the same method with the same category and options above, but the callkit button still does not reflect the correct state.
I also created a radar for the issue since it seems to be a bug with CallKit: FB16380927
There seems to be a bug with the speaker button in callkit. When you toggle it on/off, it updates the correct audio route, but does not update the state of the button. So you have to press it twice:
FB16380927