DESCRIPTION OF PROBLEM When my Document-based macOS SwiftUI app starts up, it always presents a document picker. I would like it to open any documents that were open when the app last quit, and if none were open, open an "Untitled" document. I understand that there is a setting in System Settings-> Desktop & Dock ("Close windows when quitting an application") that will cause windows to reopen when it is turned off, but I'd like to give users a chance to opt-in for reopening docs even when that is turned on, since it is difficult to find, on by default, and might not be the desired behavior for all apps. I don't see any way to get a list of currently open documents to persist them at shutdown. And even if that's considered a bad idea, I'd at least like a way to prevent the Document picker from being shown at startup and instead create an Untitled document if no documents were open. Ideally, I'd like a way to provide this functionality in SwiftUI that doesn't require macOS 15 or later STEPS TO REPRODUCE Create a SwiftUI macOS document application in Xcode using the provided template, Give it any name you want Run it, create a new ".exampletext" document, save it. Quit the app with the document open. Re-run the app, document picker is shown. Cancel the document picker and quit the app with no windows shown. Re-run the app, document picker is shown.

When transferring files in a Multipeer Session, using the Progress instances (returned by either sendResource in the sender or the delegate method session(didStartReceiving:) on the receiver) in a SwiftUI ProgressView will eventually cause a crash (EXC_BAD_ACCESS in swift_retain on com.apple.MCSession.syncQueue) I have created a small sample project that demonstrates the problem. It can be found at: https://github.com/eidria/Multipeer-Progress-Demo.git. A screen shot of the stack trace from a crash (crash.jpg) is in the “Images” folder. STEPS TO REPRODUCE Run the sample on two different hosts connected to the same network (project contains both iOS & macOS targets, bug manifests in any combination). When the second instance comes up, they will automatically find and connect to each other. When the “Send Files” button is enabled, clicking it will cause the sender to repeatedly send the file “Image.HEIC” from the “Images” folder to the receiver, which deletes it upon receipt of a successful transfer (i.e. delegate call back is called with a nil error). Subsequent transfers are triggered when the sender receives notice that the prior send completed successfully. Eventually, after some (usually small) number of files have been transferred, either the sender or receiver will crash in the middle of a transfer, with EXC_BAD_ACCESS in swift_retain on com.apple.MCSession.syncQueue. Commenting out the ProgressView in the file FileTransferView.swift will allow the apps to run in perpetuity.

I recently added Swift compiler flags intended to catch concurrency warnings that will become errors in the future, adding -Xfrontend -warn-concurrency -enable-actor-data-race-checks to "Other Swift Flags" in my project build settings. These triggered both compile and runtime warnings about MainActor issues. The compile warns were about previews: Static property '_previews' isolated to global actor 'MainActor' can not satisfy corresponding requirement from protocol '_PreviewProvider', and Static property '_platform' isolated to global actor 'MainActor' can not satisfy corresponding requirement from protocol '_PreviewProvider' But more troubling is the runtime console message: warning: data race detected: @MainActor function at DataRace/DataRaceApp.swift:13 was not called on the main thread 2022-06-30 13:49:07.559517-0700 DataRace[2699:74516] warning: data race detected: @MainActor function at DataRace/DataRaceApp.swift:13 was not called on the main thread The problem appears to be within the SwiftUI framework itself, and is easy to replicate: Create a macOS SwiftUI document based app, I named my example "DataRace" Add -Xfrontend -warn-concurrency -enable-actor-data-race-checks to "Other Swift Flags" in the project build settings Change the Document declaration, changing it from a FileDocument to a ReferenceFileDocument, replacing fileWrapper() with the snapshot()/fileWrapper() required by ReferenceFileDocument: class DataRaceDocument: ReferenceFileDocument { var text: String init(text: String = "Hello, world!") { self.text = text } static var readableContentTypes: [UTType] { [.exampleText] } required init(configuration: ReadConfiguration) throws { guard let data = configuration.file.regularFileContents, let string = String(data: data, encoding: .utf8) else { throw CocoaError(.fileReadCorruptFile) } text = string } public func snapshot(contentType: UTType) throws -> Data { return text.data(using: .utf8)! } func fileWrapper(snapshot: Data, configuration: WriteConfiguration) throws -> FileWrapper { return .init(regularFileWithContents: snapshot) } } Change the App DocumentGroup to the one appropriate for ReferenceFileDocument: var body: some Scene { DocumentGroup(newDocument: { DataRaceDocument() }) { file in ContentView(document: file.document) } } } Lastly, change the ContentView to accommodate the previous changes: @ObservedObject var document: DataRaceDocument var body: some View { TextEditor(text: $document.text) } } struct ContentView_Previews: PreviewProvider { static var previews: some View { ContentView(document: DataRaceDocument()) } } Compiling after these 4 changes will show the preview warnings. Run the app, save the default document, quit & restart the app and you will see the runtime warning. The line that triggers it is in the DocumentGroup statement in the App: DocumentGroup(newDocument: { DataRaceDocument() }) { file in ContentView(document: file.document) } and breakpoints show it happening before DataRaceDocument.init() is called Any ideas?

I am using scene.write(to:"dirpath\name.usdz") to get usdz export functionality into my app (universal, macOS & iOS). My problem is, it ceases to work after the first use, quitting & restarting the app is the only way to re-enable it. I have tried reusing the same scene, and instantiating a new scene (both ways with the exact same node structure), same results every time: first invocation writes a file of ~14MB, any calls after that write 1.5-2k of garbage. I use a unique filename for each write, and check to make sure it doesn't already exist. Any ideas?

Any USDZ file exported from Reality Composer fails to import into Reality Converter. Every USDZ file I have exported from Composer (even just a cube with a default glossy paint finish anchored on a horizontal surface) fails on import to Converter with the message "Conversion Failed: 1 Error". I suspect that the problem is with Composer and not Converter, since USDZ files created by other means import into Converter just fine. Steps to repro: Enable USDZ export in Reality Composer (Preferences/Enable USDZ export) Add a cube Export USDZ, current scene only (although this seems to make no difference) Open Reality Converter Drag USDZ file from step 3 into the window Observe error message Better import diagnostics would be good too.