Close Menu
geekfence.comgeekfence.com
    What's Hot

    ClickFix attackers using new tactic to evade detection, says Microsoft – Computerworld

    March 7, 2026

    M&A Monthly: February/March 2026

    March 7, 2026

    Posit AI Blog: luz 0.4.0

    March 7, 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 Read0 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

    I wish I could be an OpenClaw Maintainer

    March 7, 2026

    Swift factory method design pattern

    March 6, 2026

    react native – How to solve “”xcodebuild” exited with error code 65.“ – error from npx expo run:ios?

    March 5, 2026

    Post | Cocoanetics

    March 1, 2026

    Swift abstract factory design pattern

    February 28, 2026

    Flutter: Force portrait UI on tablets (iOS + Android) even when device is landscape, but avoid letterboxing / black bars

    February 27, 2026
    Top Posts

    Hard-braking events as indicators of road segment crash risk

    January 14, 202619 Views

    Understanding U-Net Architecture in Deep Learning

    November 25, 202518 Views

    How to integrate a graph database into your RAG pipeline

    February 8, 202610 Views
    Don't Miss

    ClickFix attackers using new tactic to evade detection, says Microsoft – Computerworld

    March 7, 2026

    “And all Windows computers should already be restricted so that random, unsigned (not signed by…

    M&A Monthly: February/March 2026

    March 7, 2026

    Posit AI Blog: luz 0.4.0

    March 7, 2026

    Top Reasons to Choose Precisely for SAP and Salesforce Process Automation

    March 7, 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

    ClickFix attackers using new tactic to evade detection, says Microsoft – Computerworld

    March 7, 2026

    M&A Monthly: February/March 2026

    March 7, 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.