Post

Replies

Boosts

Views

Activity

FileDocument project executes ContentView(document:) twice
When I transitioned my document project to iOS 18.4 from iOS 17.4, the DocumentGroup's closure runs twice both on device, and simulator. This means that if this closure runs say ContentView(document:), it does this twice in iOS 18.4 (probably 18.x). This project uses FileDocument I created a new document project from the document app template, and it exhibits the same double load behavior in iOS 18.4, and single load behavior in iOS 17.4. Both tests are run in the simulator. Does this behavior reflect a semantic requirement where the app should be able to work with multiple document loads, or is this a bug in the document system. Compiling with Swift 5 or Swift 6 for iOS 18.4. The template provided FileDocument adopted document is used with no changes. ...App.swift: import SwiftUI @main struct Double_Document_Start_ProblemApp: App { var body: some Scene { DocumentGroup(newDocument: Double_Document_Start_ProblemDocument()) { file in ContentView(document: file.$document) } } } =========================== ContentView.swift: import SwiftUI struct ContentView: View { static private var startCount: Int = 0 @Binding var document: Double_Document_Start_ProblemDocument var body: some View { Text(document.text) .onAppear { Self.startCount += 1 // GDEBUG print("Text start: \(Self.startCount).") } //TextEditor(text: $document.text) } } #if false #Preview { ContentView(document: .constant(Double_Document_Start_ProblemDocument())) } #endif =========================== Copy/paste of console output: Text start: 1. Text start: 2. ===========================
Topic: UI Frameworks SubTopic: SwiftUI
1
0
37
Apr ’25
Xcode 16.3 Compile fails
After updating to 16.3, my project now fails to compile with the diagnostic: "Command SwiftCompile failed with a nonzero exit code". This is a SwiftUI document project with two local packages, the second of which is a rather large one with 112 SwiftUI files. It is this second package that is failing. There are no issues when compiling with 16.2. Without diagnostics I'm having a bit of difficulty in determining the cause. My thought is to regress the commits unit 16.3 gives a success, or shows issues. Although I'm not catching a similar issue in the forums, I'm seeing other problems with 16.3. Has anyone else had such build failure isolated to 16.3? Any advice on other ways to approach this problem? Thanks in advance
5
0
204
Apr ’25