In solution #3, how do you report changes back to the parent observable object?

[0ranga]

First of all, thank you for this article, it is very interesting and informative! I happened to stumble upon the same kind of problems while developing an iOS app.

I do have one question, in solution #3 you mentioned:

And, if necessary, you can report changes back to the parent observable object.

Can you explain how you would do that please?

[peruginni]

Hello, glad to hear that article was handy. Thanks for the question!

First I'd like to highlight that on WWDC 2023 Apple addressed these redraws using @Observable macro. So our suggestions (like splitting to multiple objects) might not even be needed in most cases. Now SwiftUI will redraw only those parts of UI for whose the related model property actually did change, and does not redraw unrelated UI. I didn't tried it yet but seems that it might be backward compatible to older iOS versions, since Swift 5.9 macros are generating helper code that is compiled with app, so just depends if it generates something that is able work within SwiftUI on older iOS versions. I will post here if I found out more details. For more information see: https://developer.apple.com/wwdc23/10149

But if you need to report changes back to parent, I've added examples of few options:

• https://github.com/Showmax/ios-swiftui-redraws/commit/70d34d7135dfbfb334f3b83d55deb4e90bb75971

1) Example3b.swift via closure in child object, parent will use it for listening

• I would pick this for quick experiments
• good: quick to do, easy to understand
• bad: boilerplate in parent object, might need lot of didSet { reportDidChange(self) }
• demo: https://github.com/Showmax/ios-swiftui-redraws/assets/62856/7cbe1e3a-70ad-4480-afb7-e40b84c24444

2) Example3c.swift via property publishers (for specific changes) or objectWillChange (for all changes)

• I would pick this for most cases
• good: in child object no extra code, in parent just subscriptions to publishers
• little bad: tightly coupled to child publishers, but OK in most cases I think
• demo: https://github.com/Showmax/ios-swiftui-redraws/assets/62856/998caa04-ae5b-400a-96c4-0f24eecf4a41

3) Example3d.swift via common external manager

• I would pick
  • if child object uses some common external manager (for example for saving list of favourites), then parent can listen directly to this manager which can notify others that something changed
  • if there is long distance to from child to parent
• good: more decoupled
• example: https://github.com/Showmax/ios-swiftui-redraws/assets/62856/4e9e99e0-ef76-4ddb-8ea9-3c133950f5f6

I also noticed this is nicely handled in TCA architecture (but then all your components have to use this architecture).

• Search for case twoFactor(PresentationAction<TwoFactor.Action>)
  • then parent object Login is notified when child component TwoFactor do some action
• https://github.com/pointfreeco/swift-composable-architecture/blob/main/Examples/TicTacToe/tic-tac-toe/Sources/LoginCore/LoginCore.swift

[0ranga]

Thanks a lot for taking the time to answer in such details!

The info you provided is really helpful. Indeed, the new changes announced at the WWDC are quite exciting, I'm only concerned that it might not be backward-compatible. Same as you, I haven't had the time to inform myself about that yet so your comments are still very useful ;)