Updating a SwiftUI view’s state on navigating back

Colin Wren
2 min readAug 17, 2024

--

I’ve recently been exploring SwiftUI as a means to redo JiffyCV, a React Native based app I built a couple of years ago.

JiffyCV had a CV editor that contained a tab view that would allow a user to see a preview of the CV in one tab, select the entries to include in the CV in another and select the theme for the CV and some other customisations in another.

In React Native I had created the CV preview using a webview and I could rely on the render lifecycle of React to re-render that view on navigating back to it.

In SwiftUI I implemented the CV editor as a NavigationView with NavigationLinks going off to the appropriate view for the editor to make changes to the CV’s configuration and coming back to see the results.

I also decided to remove the need for a webview in the CV preview as this had caused some inconsistencies in the original JiffyCV as on iOS the webview used Safari and we had a web service that used Chrome to create the PDF.

Instead as I was targeting iOS natively I could render the PDF in the view itself and update it on fly, giving the user a much more consistent representation of the final result.

Rendering a PDF in a SwiftUI View using PDFBlocks

encountered an issue though, when I pressed Back on the view for updating the data for the CV the CV wouldn’t automatically update.

I believe this was due to the fact that the CV preview data was stored in state and not as a SwiftData model so wasn’t part of the same observation based render cycle.

So I had to find a means to trigger a re-render of the PDF by updating the CV preview data in state on navigating back.

Triggering a state change on coming back to a view

As I couldn’t rely on listening to updates on the SwiftData models I had to instead look for other ways to do it.

I had initially looked to do this by looking at changes in the navigation stack. I added an onChange listener to check the NavigationPath and if the new value was one less than the old value then it would suggest the view had been popped.

I eventually found that onAppear worked better for triggering the render, wrapping the render in a Task so it didn’t block anything.

using onAppear to re-render PDF

This worked for both the initial navigation to the view and coming back which sold me on using this approach.

--

--

Colin Wren
Colin Wren

Written by Colin Wren

Currently building reciprocal.dev. Interested in building shared understanding, Automated Testing, Dev practises, Metal, Chiptune. All views my own.