Post not yet marked as solved
Building on zulfishah's solution, just executing the button closure in an async context fixes the issue for me.
Button(role: .destructive) {
Task {
deleteObject()
}
} label: {
Label("Delete", systemImage: "trash.fill")
}
Post not yet marked as solved
We also have this issue. Feedback submitted some time ago under FB13201571.
Editing works, as long as NavigationStack is not used. This works.
struct ListSelectionTest: View {
@State var selection: Set<String> = []
let strings = ["One", "Two", "Three"]
var body: some View {
VStack {
EditButton()
List(selection: $selection) {
ForEach(strings, id: \.self) { string in
Text(string).tag(string)
}
}
}
}
}
The problem appears when the List is wrapped in NavigationStack. This only works when the EditButton is tapped TWICE.
struct ListSelectionTest: View {
@State var selection: Set<String> = []
let strings = ["One", "Two", "Three"]
var body: some View {
NavigationStack {
VStack {
EditButton()
List(selection: $selection) {
ForEach(strings, id: \.self) { string in
Text(string).tag(string)
}
}
}
}
}
}
Replacing EditButton with a custom Button produces a different visual error. Editing is set correctly, but the multi-selection indicators quickly appear and then disappear again.
struct ListSelectionTest: View {
@Environment(\.editMode) private var editMode
@State var selection: Set<String> = []
let strings = ["One", "Two", "Three"]
var body: some View {
NavigationStack {
VStack {
Button((editMode?.wrappedValue.isEditing ?? false) ? "Done" : "Edit") {
editMode?.wrappedValue = (editMode?.wrappedValue.isEditing ?? false) ? .inactive : .active
}
List(selection: $selection) {
ForEach(strings, id: \.self) { string in
Text(string).tag(string)
}
}
}
}
}
}
In short, we suspect there is a SwiftUI bug related to triggering List editing when the list is in NavigationStack.
Post not yet marked as solved
Same problem here. I'm struggling with extracting NavigationPath() into a separate class using @Observable.
When this class is marked as @Observable, typing NavigationStack(path: viewModel.path) {...} results in error:
Cannot convert value of type 'NavigationPath' to expected argument type 'Binding<NavigationPath>'
Variations like $viewModel.path or viewModel.$path do not work either.
The only "working" solution is:
var body: some View {
@Bindable var bindable = viewModel
NavigationStack(path: $bindable.path) {...}
}
But this is very hacky.
Post not yet marked as solved
I still have this issue. When working with Map() and MapAnnotation(), I get swamped by console prints and purple warnings. Apple please provide a fix or advice!
Post not yet marked as solved
I struggled with this a year ago. In the end I restructured my model so it works without unique constraints.
For example, you may have a many-to-many relationship between entities Color and Animal (an animal may have multiple colours, and vice-versa: a specific colour may be found on various animals). Without unique constraints, you can fetch animals by colour like this:
if colorFilter != .noValue {
// any animal where color in colors relationship contains value
predicates.append(NSPredicate(format: "ANY colors.color == %@", colorFilter.rawValue))
}
Post not yet marked as solved
I tried to train the model programmatically in a Swift Playground. This process also failed and returned the following error (I have no idea what it means). Training on a smaller subset of the dataset succeeds.
remoteProcessWasInterrupted
Error: ["ThreadID": 1278902, "ThreadCrashed": 1, "StackFrameDictionaries": <__NSArrayM 0x600001fe0570>(
{
StackFrameModule = vImage;
StackFramePC = 7223916652;
StackFrameSymbolName = "__ERROR_Buffer_Write__Too_Small_For_Arguments_To_vImage__CheckBacktrace";
},
{
StackFrameModule = vImage;
StackFramePC = 7223916524;
StackFrameSymbolName = "_vImageDebug_CheckDestBuffer";
},
{
StackFrameModule = vImage;
StackFramePC = 7223913756;
StackFrameSymbolName = "_vImageConvert_AnyToAny";
},
... // more fields follow
)
]
This is now confirmed by Apple as a known bug with high priority. A detailed, up-to-date post is kept at SO: https://stackoverflow.com/questions/73888519/uicloudsharingcontroller-does-not-work-for-core-data-with-cloudkit
As of iOS 16.0.3, this issue appears to have gone away when using the Apple sample app. I am still using the same downloaded code, so a fix was possibly made by Apple on CloudKit side of things.
After investigating, I still encountered the issue when invoking UICloudSharingController using UIViewControllerRepresentable (like in the RayW sample code).
The issue does not appear (anymore) when invoking UICloudSharingController using UIViewController (like in the Apple sample code).
Post not yet marked as solved
You could measure the offset of the ScrollView content and store it using Preference Keys. Then if offset > 0, it means the user scrolled. So, if offset > 0 && leadingBool == false means the ScrollView is partially scrolled. So you can do whatever you need.
PS in reality I guess you will scroll x to the negative, so it will be < 0.
Post not yet marked as solved
Same issue here. Apple pls fix!
A bug report was submitted as FB11623246
On further inspection, the same problem also manifests in other samples which use CoreData+CloudKit sharing, for example: https://www.raywenderlich.com/29934862-sharing-core-data-with-cloudkit-in-swiftui
The problem does NOT appear in samples that use pure CloudKit, such as: https://github.com/apple/sample-cloudkit-sharing
This leads me to suppose there is something weird going on between Core Data and UICloudSharingController.
On further inspection, the following console message appears when this issue happens for the first time:
CoreDataCloudKitShare[3672:1242159] systemSharingUIDidSaveShareBlock received error: <CKError 0x28314d8c0: "Server Record Changed" (14/2004); server message = "client oplock error updating record"; op = 134D57570A63DF3A; uuid = 8F070F8B-0AC0-4FFE-A52D-154BCBF3196C; container ID = “containerID>
Where containerID is the CKContainer ID, like “iCloud.com.company.samples.CoreDataCloudKitShare”. The message does not appear on subsequent attempts to add more people.
This was later resolved with Apple, but required getting in direct touch with support.
