iOS 18 changes the order of Document-based SwiftUI document reading and view loading?

Question

nima OP

Created 1w

Replies 2

Boosts 2

Participants 3

It looks like iOS 18 app changed the way document-based SwiftUI apps function in a way that breaks our app.

Previously, a ReferenceFileDocument would run its init(configuration:) function before any SwiftUI views would load. Now, it runs it after SwiftUI views load and their onAppear modifiers run.

Because we use a reference-type data model, our views reference a different object than the one loaded from our document's content. Much of our app's functionality is broken, and file saving doesn't work (because the data model writing to disk isn't connected to the views)

I filed a bug report, but this seems like a wild change that should affect more than just us. It wasn't happening earlier in the iOS betas. It feels like it only got added in the last beta, but I'm not sure.

Has anyone else run into this, or have any guidance for how best to deal with this?

Boost

Answer 1

M78 OP

1w

Yes, I have many issues too when I build my app with XCode 16. To be exact, running on iOS 18 is fine though. It's good as long as it's built with the older Xcode 15.

As far as I know, these changes affect iOS 18 but not macOS 15 Sequoia.

I have submitted a bug as well. I would really like to understand the motivation for such a radical change. And see some official migration recommendations.

2

Answer 2

BobStroggUSA OP

3d

I'm seeing similar issues, but with the basic FileDocument. It works, but now seems to be initialized on a background thread. This gives me a "Publishing changes from background threads is not allowed; make sure to publish values from the main thread (via operators like receive(on:)) on model updates." error. This even happens with Apple's own FileDocument-based template project.

Wrapping the "self." mutation in DispatchQueue.main.async doesn't help, because then it complains the escaping closure is capturing a mutating "self" parameter (and also assumes self is uninitialized at the end, because the mutation is deferred).

1