Close Menu
geekfence.comgeekfence.com
    What's Hot

    Posit AI Blog: Introducing the text package

    July 9, 2026

    Cut costs and simplify operations with writable warm storage in Amazon OpenSearch Service

    July 9, 2026

    Data centre delays expose AI cloud power limits

    July 9, 2026
    Facebook X (Twitter) Instagram
    • About Us
    • Contact Us
    Facebook Instagram
    geekfence.comgeekfence.com
    • Home
    • UK Tech News
    • AI
    • Big Data
    • Cyber Security
      • Cloud Computing
      • iOS Development
    • IoT
    • Mobile
    • Software
      • Software Development
      • Software Engineering
    • Technology
      • Green Technology
      • Nanotechnology
    • Telecom
    geekfence.comgeekfence.com
    Home»iOS Development»Understanding SwiftUI view lifecycles – Ole Begemann
    iOS Development

    Understanding SwiftUI view lifecycles – Ole Begemann

    AdminBy AdminDecember 4, 2025No Comments4 Mins Read3 Views
    Facebook Twitter Pinterest LinkedIn Telegram Tumblr Email
    Understanding SwiftUI view lifecycles – Ole Begemann
    Share
    Facebook Twitter LinkedIn Pinterest Email


    I wrote an app called SwiftUI View Lifecycle. The app allows you to observe how different SwiftUI constructs and containers affect a view’s lifecycle, including the lifetime of its state and when onAppear gets called. The code for the app is on GitHub. It can be built for iOS and macOS.

    Understanding SwiftUI view lifecycles – Ole Begemann

    Mac screenshot of the SwiftUI View Lifecycle app

    When we write SwiftUI code, we construct a view tree that consists of nested view values. Instances of the view tree are ephemeral: SwiftUI constantly destroys and recreates (parts of) the view tree as it processes state changes.

    The view tree serves as a blueprint from which SwiftUI creates a second tree, which represents the actual view “objects” that are “on screen” at any given time (the “objects” could be actual UIView or NSView objects, but also other representations; the exact meaning of “on screen” can vary depending on context). Chris Eidhof likes to call this second tree the render tree (the link points to a 3 minute video where Chris demonstrates this duality, highly recommended).

    The render tree persists across state changes and is used by SwiftUI to establish view identity. When a state change causes a change in a view’s value, SwiftUI will find the corresponding view object in the render tree and update it in place, rather than recreating a new view object from scratch. This is of course key to making SwiftUI efficient, but the render tree has another important function: it controls the lifetimes of views and their state.

    We can define a view’s lifetime as the timespan it exists in the render tree. The lifetime begins with the insertion into the render tree and ends with the removal. Importantly, the lifetime extends to view state defined with @State and @StateObject: when a view gets removed from the render tree, its state is lost; when the view gets inserted again later, the state will be recreated with its initial value.

    The SwiftUI View Lifecycle app tracks three lifecycle events for a view and displays them as timestamps:

    • @State = when the view’s state was created (equivalent to the start of the view’s lifetime)
    • onAppear = when onAppear was last called
    • onDisappear = when onDisappear was last called

    A table with three rows. @State: 1:26 ago. onAppear: 0:15 ago. onDisappear: 0:47 ago.

    The lifecycle monitor view displays the timestamps when certain lifecycle events last occurred.

    The app allows you to observe these events in different contexts. As you click your way through the examples, you’ll notice that the timing of these events changes depending on the context a view is embedded in. For example:

    • An if/else statement creates and destroys its child views every time the condition changes; state is not preserved.
    • A ScrollView eagerly inserts all of its children into the render tree, regardless of whether they’re inside the viewport or not. All children appear right away and never disappear.
    • A List with dynamic content (using ForEach) lazily inserts only the child views that are currently visible. But once a child view’s lifetime has started, the list will keep its state alive even when it gets scrolled offscreen again. onAppear and onDisappear get called repeatedly as views are scrolled into and out of the viewport.
    • A NavigationStack calls onAppear and onDisappear as views are pushed and popped. State for parent levels in the stack is preserved when a child view is pushed.
    • A TabView starts the lifetime of all child views right away, even the non-visible tabs. onAppear and onDisappear get called repeatedly as the user switches tabs, but the tab view keeps the state alive for all tabs.

    Here are a few lessons to take away from this:

    • Different container views may have different performance and memory usage behaviors, depending on how long they keep child views alive.
    • onAppear isn’t necessarily called when the state is created. It can happen later (but never earlier).
    • onAppear can be called multiple times in some container views. If you need a side effect to happen exactly once in a view’s lifetime, consider writing yourself an onFirstAppear helper, as shown by Ian Keen and Jordan Morgan in Running Code Only Once in SwiftUI (2022-11-01).

    I’m sure you’ll find more interesting tidbits when you play with the app. Feedback is welcome!





    Source link

    Share. Facebook Twitter Pinterest LinkedIn Tumblr Email

    Related Posts

    security – How and where mnemonic/private keys are generated/stored in IOS for mobile non-custodial wallet

    July 7, 2026

    JSON All the Way Down

    July 3, 2026

    ios – HKStatisticsCollectionQuery initialResultsHandler returns nil results for one specific user — read auth granted, data exists, survives reinstall

    July 2, 2026

    Installing simulator runtimes from the command line – Donny Wals

    June 29, 2026

    SwiftText Learns to Write | Cocoanetics

    June 28, 2026

    uitabbarcontroller – UITabBar unselectedItemTintColor ignored iOS 26

    June 27, 2026
    Top Posts

    Understanding U-Net Architecture in Deep Learning

    November 25, 202560 Views

    Hard-braking events as indicators of road segment crash risk

    January 14, 202631 Views

    Redefining AI efficiency with extreme compression

    March 25, 202628 Views
    Don't Miss

    Posit AI Blog: Introducing the text package

    July 9, 2026

    AI-based language analysis has recently gone through a “paradigm shift” (Bommasani et al., 2021, p. 1),…

    Cut costs and simplify operations with writable warm storage in Amazon OpenSearch Service

    July 9, 2026

    Data centre delays expose AI cloud power limits

    July 9, 2026

    5 Settings That Make Readings Easier to See

    July 9, 2026
    Stay In Touch
    • Facebook
    • Instagram
    About Us

    At GeekFence, we are a team of tech-enthusiasts, industry watchers and content creators who believe that technology isn’t just about gadgets—it’s about how innovation transforms our lives, work and society. We’ve come together to build a place where readers, thinkers and industry insiders can converge to explore what’s next in tech.

    Our Picks

    Posit AI Blog: Introducing the text package

    July 9, 2026

    Cut costs and simplify operations with writable warm storage in Amazon OpenSearch Service

    July 9, 2026

    Subscribe to Updates

    Please enable JavaScript in your browser to complete this form.
    Loading
    • About Us
    • Contact Us
    • Disclaimer
    • Privacy Policy
    • Terms and Conditions
    © 2026 Geekfence.All Rigt Reserved.

    Type above and press Enter to search. Press Esc to cancel.