Probably a rookie question; sorry. I notice that Paul's code regularly performs an objectWillChange.send() then modifies one or more values. This triggers the view(s) to update and re-render.

My brain, such as it is, is struggling with the process going on here. If we tell the view that an object is going to change and to render itself, but the actual property change takes a while to happen, isn't it possible that the view will render with the old data?

In my code, I have gotten in the habbit of updating the values and then doing objectWillChange.send(). I'm positive that this is the wrong way to do it, but I don't know why. In my head, I want to say that updates are starting to happen, do the updates, then say they're complete so there is only one view refresh. However, the only option I appear to have is to say that something is about to change.

objectWillChange.send() is one of those lines of code I have got in the habbit of using and I've never really thought about why it works.

Thanks Steve

I get this, but it leaves me with the question, when will my order go to the kitchen? If orderWillBePlaced leaves me free to keep changing the order (preferably with a different waiter) right up until the restaurant closes so, what signals to the waiter that they can send my order through and that I will no longer be able to make changes? What's the signal that my pending order is a firm order?

Is it as simple as objectWillChange.send() signals that 'something' will change and the trigger to the view to refresh will be sent when the function completes?

p.s. I would have replied earlier, but this edit box does not work well on an iPad!

hi,

i have a plausible, working theory about how SwiftUI really works. i'll throw it out here ... if you accept it, the "willChange" emphasis over "didChange" might make sense. or at least i think it does.

and if someone wants to jump in and tell me i'm not quite on the mark, i would welcome that comment. i'd really like to understand it myself.

SwiftUI basically manages what's shown on screen. when the body of a View is executed, SwiftUI does not immediately draw anything on screen. rather, when the body is executed, SwiftUI builds an internal representation of what should go to the screen. when it actually gets to the screen ... well, that's up to SwiftUI to decide.

i believe that SwiftUI maintains such an internal representation of what it last moved to the screen.

when SwiftUI sees a change in the data that underlies a View ... e.g., a change in a @State variable, or a change in a @Published property of an associated view model that it is observing ... the body property will be executed and a new internal representation will be generated.

then the new internal representation will be "diffed" against the previous one, and that tells SwiftUI what changes need to be made on-screen (e.g., views added, views changed, views removed, and animations to be done).

then the old internal representation is discarded and the new representation is kept for future changes.

if that's really true (!), then SwiftUI always needs to have an internal representation of what is on-screen, so it can compare against any future changes.

but:

• SwiftUI, after all, does its own memory management, and may choose to release an internal representation for a View it is holding from a previous redraw of the screen, at any time, whether under memory pressure or not.

• and there could be optimization involved in this process. if A then B then C send objectWillChange messages in sequence, perhaps diffing will be simpler with a sequence of small changes, rather than one large diffing operation where all changes are incorporated in one large operation.

so, by sending objectWillChange before making changes to data underlying a View, you send a signal to SwiftUI that if it has released its previous internal representation of a View, now would be a good time to run the body property now so that it is in sync with what it knows is on-screen.

once you make data changes, it is SwiftUI's turn to run the body property with the changes, and it can properly diff what it knows is on-screen now with what should next be on-screen with the new data changes. SwiftUI can then update the screen correctly.

again, comments welcomed!

hope that helps,

DMG

The book "Thinking in SwiftUI" by objc.io says a @Published property of an ObservableObject is an objectWillChange publisher. This is consistent with DMG's explanation. The book does not mention objectDidChange anywhere.

A possibly interesting contrast is that Matt Neuburg's book "iOS Programming", which predates SwiftUI, consistently teaches view controllers subscribing to didChange, not willChange, notifications.