Close Menu
geekfence.comgeekfence.com
    What's Hot

    TX Fiber taps Vecima for XGS-PON roll out

    May 11, 2026

    From Planning to Action: SAP Enterprise Planning enhanced by DataRobot

    May 11, 2026

    How to Fix Your Claim Denial Rate with Expert Outsourcing

    May 11, 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

    ios – How to add shadow to border?

    May 11, 2026

    Introducing SwiftPorts | Cocoanetics

    May 7, 2026

    Awesome native Xcode extensions – The.Swift.Dev.

    May 6, 2026

    ios – Flutter UI not matching design: top-right badge not properly attached to card border

    May 5, 2026

    Four Green Checkmarks: GitHub CI for macOS, iOS, Linux, and Windows

    May 1, 2026

    Swift enum all values – The.Swift.Dev.

    April 30, 2026
    Top Posts

    Understanding U-Net Architecture in Deep Learning

    November 25, 202539 Views

    Hard-braking events as indicators of road segment crash risk

    January 14, 202627 Views

    Redefining AI efficiency with extreme compression

    March 25, 202626 Views
    Don't Miss

    TX Fiber taps Vecima for XGS-PON roll out

    May 11, 2026

    Vecima Networks Inc. (TSX: VCM) today announced that TX Fiber, a leading independent fiber broadband…

    From Planning to Action: SAP Enterprise Planning enhanced by DataRobot

    May 11, 2026

    How to Fix Your Claim Denial Rate with Expert Outsourcing

    May 11, 2026

    Powering an Inclusive Future: Your guide to the Purpose Pavilion at Cisco Live Las Vegas

    May 11, 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

    TX Fiber taps Vecima for XGS-PON roll out

    May 11, 2026

    From Planning to Action: SAP Enterprise Planning enhanced by DataRobot

    May 11, 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.