Same issue here. Can't believe it was forgotten to be actually able to rename a document file with a DocumentGroup.
I'm using Xcode Version 12.2 beta 4
Even if I create a new iOS app with the Document App template I can't rename the file. It is working though when I crate a new Document App for macOS. There it lets me edit the filename in the top bar.
Post
Replies
Boosts
Views
Activity
Sorry, I should have been more specific. I'm using this on macOS which will automatically implement undo/redo functionality for the document. I was assuming this was done on iOS as well. So thanks for this answer:didSet gets called for every update from the GUI, but when I undo the change (CMD + Z or from the menu) it does not get called.
I don't know how exactly document undo/redo functionality is implemented, but I would assume that there's an internal copy of the complete document saved for each undo/redo step (which might be actually not as inefficient through use of copy-on-write semantics?) That means the complete document gets switched out and didSet doesn't get called. Any ideas how I could react to changes on undo/redo?
Hmm, I think it only works on TextEditor, which is the default in a new document-based app. If you replace it with TextField, undo doesn't call didSet anymore. Also any other action (e.g. adding / removing and array item) in the document doesn't call a didSet on undo. This is quite strange...
Thanks @rnikander,
you're right, the upgrade helped fixing it. Seems like this minimal example was fixed. I still have a problem with my big app, though. Now, seems to be correlated to the toolbar component.
I created a new thread with a new minimal example for this ( https://developer.apple.com/forums/thread/677969 ) Can you check if this is is causing problems on your end?
Johannes
Note: If I change the app to this, there's no more leak because now the toolbar doesn't get invalidated and recreated.
Swift
import SwiftUI
@main
struct TestApp: App {
var body: some Scene {
WindowGroup {
TestView()
.toolbar(content: {
ForEach(1...100, id: \.self) { _ in
Text("Hello World")
}
})
}
}
}
struct TestView: View {
@State var strings = ["Hello 1", "Hello 2"]
@State var bool = false
let timer = Timer.publish(every: 0.1, on: .main, in: .common).autoconnect()
@State var selected: Int?
var body: some View {
List(strings.indices, id: \.self, selection: $selected) { stringIndex in
Text(strings[stringIndex])
}
.onReceive(timer) { input in
if bool == true { selected = 0 }
else { selected = 1 }
bool = !bool
}
}
}
This is not possible for my original app though, because I need to dynamically switch the toolbar depending on context. This still seems like a pretty significant bug. How can I work around this?
Dear Apple,
please fix this problem. With the simple app above the memory footprint quickly grows to gigabytes and when profiling with the Leak Detector, I see a huger number of leaks in SwiftUI internals. I spent quite some time and resources to build my app where this bug manifests and it prevents me from releasing it. How can such a big problem not be addressed? This is a very minimal and simple app and it still has this huge issue.
Even though this is most noticeable with the Toolbar it manifests itself in other areas. In my app, the amount of leakage is drastically reduced when I remove the toolbar, but it still continues to leak when changing the State.
Johannes