I think @lukeredpath's answer is probably best for a quick fix and directly getting what you want, but I would also agree that more context would be needed to give an optimal answer. I think that for the most consistent codebase it really would be best to move this sort of stuff directly into reducers and environments.
In my experience with this architecture, views are best limited to 1. rendering the view based on the state and 2. sending actions to the store. So any unit of work that needs to run should really be wrapped in an effect that feeds back into the reducer, and then the views can re-render themselves based on any changes to the state.
If it's UIKit code, this is definitely not the "usual" way things are done, where state tends to be kinda littered throughout the code. But this sort of approach can really aid in modularity & testability.