Designing Apps for SwiftUI

Question

Created Sep ’19

Replies 3

Boosts 0

Participants 3

The Destination of a NavigationLink is instantiated, but not displayed, when the View with the NavigationLink is instantiated. If the destination view then performs a significant amount of processing every time the origin view changes, but prior to the destination view needing display, there can be significant degradation of app performance. E.g. I've added SwiftUI Views to an existing app in order to analyse accumulated data; the user selects filter and statistics parameters from Pickers prior to pressing the "Calculate" button (NavigationLInk). The Link destination is instantiated and executed (eg data calculations)every time a property (e.g. filter selection) changes in the origin view before the user has pressed the Calculate button.

Also, I assume that all subviews of a View are instantiated when the parent View is instantiated, even though they may not all be on screen. Add to this the fact that ObservedObjects, when changed, trigger a redisplay of any/all? containing Views.

So, all of this leads me to suggest that design of SwiftUI apps is critical, especially where the app has many views and/or there is complex processing as a result of user interaction.

I look forward to suggestions and/or pointers to best-practice design.

Regards,

Michaela

Boost

Answer 1

Claude31 OP

Sep ’19

I have a more blunt question. Do I need to use SwiftUI ? 😉

0

Answer 2

AncientCoder OP

Sep ’19

Good question Claude. Once over the learning curve, I've found developing new screens/functionality to be much faster than with UIKit. I also really like having an ObservableObject singleton data model, with Published attributes, as the sole source of truth within the app, rather than passing data backwards and forwards between views with segues. But, the behaviours described in my post worry me, plus I haven't yet got my mind around thread-safety issues.

0

Answer 3

KMT OP

Sep ’19

> Do I need to use SwiftUI ?

Paraphrasing Hw/S... do you like that "storyboards and XIBs rely on a flaky system of connections using actions and outlets, make it hard if not impossible to move between code and visual layouts, and can be messy to use with source control?"

If you do, then maybe not. Stay where you are and be happy.

If you don't, know that "SwiftUI sweeps all that away in at least four important ways:

There’s a new declarative UI structure that defines how our layouts look and work.
Updating the UI preview automatically generates new Swift code, and changing the Swift code updates the UI preview.
Any bindings in the Swift – e.g. outlets and actions, effectively – are now checked at compile time, so there’s no more risk of UI failing by surprise at runtime.
Although SUI uses controls from UIKit and AppKit behind the scenes, it sits on top of them, effectively making the underlying UI framework an implementation detail rather than something we're forced to care specifically about it."

0