Xcode 12 beta 6 has changed the SwiftUI FileDocument protocol and broke my tests.

[zorn]

Seems the updates to FileDocument have changed the required init and write calls to something like:

    init(configuration: ReadConfiguration) throws {
        guard let data = configuration.file.regularFileContents,
              let string = String(data: data, encoding: .utf8)
        else {
            throw CocoaError(.fileReadCorruptFile)
        }
        text = string
    }
    
    func fileWrapper(configuration: WriteConfiguration) throws -> FileWrapper {
        let data = text.data(using: .utf8)!
        return .init(regularFileWithContents: data)
    }

ReadConfiguration is a typealias of FileDocumentReadConfiguration

typealias ReadConfiguration = FileDocumentReadConfiguration

This looks like a public struct:

/// The configuration for reading file contents.
@available(iOS 14.0, macOS 11.0, *)
@available(tvOS, unavailable)
@available(watchOS, unavailable)
public struct FileDocumentReadConfiguration {

    /// The expected uniform type of the file contents.
    public let contentType: UTType

    /// The file wrapper containing the document content.
    public let file: FileWrapper
}

BUT in my tests I used to make fixture instances of PeopleDocument with:

    static var simpleV1: PeopleDocument {
        return try! PeopleDocument(fileWrapper: simple(version: 1), contentType: UTType.peopleDocumentType)
    }

I tried to convert this to match the changes but not seeing how to make a FileDocumentConfiguration

    // ERROR: 'FileDocumentReadConfiguration' cannot be constructed because it has no accessible initializers
    static var simpleV1: PeopleDocument {
        let configuration = FileDocumentReadConfiguration(contentType: UTType.peopleDocumentType, file: simple(version: 1))
        return try! PeopleDocument(configuration: configuration)
    }

Also have tried:

    // ERROR: 'PeopleDocument.ReadConfiguration' (aka 'FileDocumentReadConfiguration') cannot be constructed because it has no accessible initializers
    static var simpleV1: PeopleDocument {
        let configuration = PeopleDocument.ReadConfiguration(contentType: UTType.peopleDocumentType, file: simple(version: 1))
        return try! PeopleDocument(configuration: configuration)
    }

Ideas?

[zorn]

Posted this on the Apple Dev Forums:

https://developer.apple.com/forums/thread/658610

[EricShapiro]

Same problem here. ¯\(ツ)/¯

[zorn]

I've worked around the issue for now, but still looking for a long term solution.

Also asked on these forums to no avail as of yet:

https://www.hackingwithswift.com/forums/swiftui/new-swiftui-filedocument-protocol-how-do-init-a-readconfiguration-during-testing/3545

[Joebeazelman]

Any luck with the issue? Without this functionality, not only is it impossible to test my code, but impossible for me to create a code my view using SwiftUI. I was hoping to construct a ReadConfiguration by passing it a path or a file URL so I can pass it to my document object. This sucks!

I'm an Apple fanboy coming from the world of .NET C#. So far in my short journey learning Swift, this is the biggest snag I've encountered thus far. Microsoft gets everything wrong, including developer tools and languages, but if you look hard enough, you'll eventually find an answer.

I've looked through Apples documentation and it's actually worse than Microsoft's. Many of the functions have no example code snippets and many of the descriptions are one liners. This doesn't bode well for me. It sours my high expectations of excellence from Apple. Maybe I should wait for Microsoft's upcoming MAUI.

[zorn]

@Joebeazelman So sorry to hear this is blocking you.

I am not actively doing any Apple development. This issue is from an older proof of concept project I did for a friend. I'm not in a place to give you any guidance. So sorry.

[Joebeazelman]

Thanks. No problem. At least I know it can't be resolved.

[deirdresm]

Ran across your questions in All The Places™ and thought I'd respond as it was a challenge I ran into as well, and others will too.

The dead simple workaround (which, doh, should have realized) is just to provide an initial value for the document in the view's variable. (You can wrap that in #if DEBUG if that makes sense for your context and provide a different alternative for non-DEBUG.)

Obviously not an ideal thing as it doesn't flex the API at the point it needs, but it at least is a point one can get past. Plus it works with previews.