Close Menu
geekfence.comgeekfence.com
    What's Hot

    Emerald Fennell’s Wuthering Heights Review

    February 14, 2026

    Infrastructure, Not Compute, is the Real AI Bottleneck

    February 14, 2026

    ALS stole this musician’s voice. AI let him sing again.

    February 14, 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

    The importance of human touch in AI-driven development – Donny Wals

    February 12, 2026

    Bug: Progress with Child | Cocoanetics

    February 11, 2026

    Swift command design pattern – The.Swift.Dev.

    February 10, 2026

    SwiftUI TabView (.page / PageTabViewStyle) selection can get out of sync when user interrupts a programmatic page change

    February 9, 2026

    An Introduction to Liquid Glass for iOS 26

    February 7, 2026

    DTCoreText 1.6.27 | Cocoanetics

    February 5, 2026
    Top Posts

    Hard-braking events as indicators of road segment crash risk

    January 14, 202617 Views

    Understanding U-Net Architecture in Deep Learning

    November 25, 202512 Views

    How to integrate a graph database into your RAG pipeline

    February 8, 20268 Views
    Don't Miss

    Emerald Fennell’s Wuthering Heights Review

    February 14, 2026

    Summary created by Smart Answers AIIn summary:Tech Advisor highlights six critical errors in Emerald Fennell’s…

    Infrastructure, Not Compute, is the Real AI Bottleneck

    February 14, 2026

    ALS stole this musician’s voice. AI let him sing again.

    February 14, 2026

    What is Prompt Chaining?

    February 14, 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

    Emerald Fennell’s Wuthering Heights Review

    February 14, 2026

    Infrastructure, Not Compute, is the Real AI Bottleneck

    February 14, 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.