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

Question

nima OP

Created Sep ’24

Replies 3

Boosts 2

Participants 4

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

Sep ’24

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

Sep ’24

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

Answer 3

cm212 OP

2w

Same problems here. It also looks like all classes initialized stay alive when you close a document and only deinit when you open/create another document. Eventually I'm not able to open/create any documents and have to relaunch my app. Following along for updates -- not sure what to do.

0