Performance considerations using ViewThatFits

The performance considerations really depend on your specific use case, especially if the views you're asking ViewThatFits to choose between are complex, since you're effectively initializing and measuring each candidate view and all of its children, and this happens on every layout pass.

For resizability, the best way to react to changes in size is by tracking size class changes for overall window size, or onGeometryChange for tracking the size of individual views. The nice thing about this is that it gives you more control over the thresholds at which the decision of which view to display happens.

Instead of making a conditional view decision on every frame of a resize action, you could try defining "break points" for your layout. For instance, you might code up some logic where when the parent view's width moves between certain ranges, you set a state variable that specifies which view to show. onGeometryChange's action closure only fires when the value returned by its transform closure changes, so this allows you to limit the frequency of updates to the specific transition points that matter to you, instead of updating on every frame.

That being said, ViewThatFits might be just fine for your use case. Ultimately, the best way to know if you're running into any performance issues is to use the SwiftUI instrument in Instruments to look at how much work is happening as you're resizing.

ViewThatFits attempts to size the views from top to bottom given to it. This means that when the last view is chosen that all views before it have been fully initialized (SwiftUI builds the graph for the view) and measured. This is repeated every time the view is invalidated or the parent layout system changes. Try to minimize invalidations by putting the ViewThatFits into a separate view.

Custom layouts can also be a good alternative. One benefit is that SwiftUI only actually fully initialize the views once and you are just measuring those in different ways and placing them. Animations work better too when views change their position through a custom layout.

Another alternative would be to use AnyLayout and switch dynamically between layouts. This also allows SwiftUI to reuse the underlying graph of the views and just remeasures them and positions them at a different places.

Thanks a lot for your comment and things to consider! 🙏

I use that for different cases already – from small large text tweaks to custom grid layouts that change depending on window size – so I’ll check out the alternatives and see if it makes sense to switch.