Once you’ve introduced a state based caching and differentiation layer, you’re introducing retention and are entering into hybrid UI. If you don’t have sufficient caching layers to figure out when something has to update, you’re drawing too often killing battery.

Maybe there are fewer purely immediate mode UI libraries today, which muddies the discussion though.

On the note of the apps used, I would say the vast majority of apps I run only have a few elements updating at any given time. Most of them are based on scrolling for navigation but that’s a small part of what I do. Photo viewing and editing, viewing sites, replying to messages or mail, listening to music. Very little is a full screen update, and if it is, UIKit and SwiftUI are caching large amounts of the view objects to keep things snappy and only doing it when they receive input that requires it. Can immediate GUIs do that too? Of course, but again you enter the domain of retention.

> you’re drawing too often killing battery.

You say this with zero proof. Checking 100s of widgets to see if they overlap, updating their damage boxes, drawing the parts of the ones that got overlapped, computing clip bounds for each one, switching graphics contexts, to do all that adds up to "killing the battery"

Retained APIs are like using a binary tree where an Immediate mode GUI is like using a vector. CS principles say the tree should be faster as insert and delete are in O(1) but in reality, cache misses and similar things kill all the perf you supposedly gained by over engineering the solution.

The same is often true of retained mode GUIs vs immediate, especially with all the transparency effects in modern UIs. Computing the minimal amount of parts can requires a ton more CPU than just drawing.

As far as caching = retained, no. The difference between an Immediate Mode and a retained mode API is if you, the user, have to create and maintain a tree of retained API widgets. No one is going to implement an immediate mode API and try to have a text widget that word wraps and expect it to have to compute all the word wrapping every frame.

Except you’d not be doing all those things that you mentioned. Much like you wouldn’t in a game, you’d be constructing some kind of acceleration structure to only update what’s needed.

With an immediate mode GUI, you have to typically draw most of the hierarchy when even a single widget changes unless you maintain a state based cache. You’re inherently calculating construction of more unless you’re also doing the same optimizations that a retained mode system does.

The tree vs vector analogy isn’t correct either because neither mode prescribe a data structure. I know it was meant to be an analogy but I don’t think it really applies because it doesn’t reflect most code bases and frameworks.

Maybe our definitions of immediate vs retained don’t align.

As for metrics, I don’t have any on hand, and that perhaps makes the discussion moot, but we’ve done multiple UI implementations on my projects, and immediate UIs don’t compare favourably for energy use until and unless you introduce a retained backing.

Indeed that’s what interfaces like Flutter and SwiftUI do by exposing a React+immediate style API while working over a retained base.

I wish I could share our metrics, and I recognize there’s no reason for you to take me at my word on that, but we have done significant work in this area to compare systems for our projects. For reference , we often make use of multiple APIs across our different apps like Dear,Imgui and SwiftUI depending on their needs.