Simplify Iris app initialization and task updates

docs/PLAN.md

@@ -794,13 +794,24 @@ ssh case are one implementation.
 
 **An Iris Android application supplies an initialization function and its own
 state/resources; Iris supplies the JNI host and APK packager.**
-`#[iris::app_init]` marks the factory Android calls when it creates the Iris
-view. The macro target-gates the factory and generates the single exported
+`#[iris::app_init]` marks the initializer Android calls when it creates the Iris
+view. The macro target-gates the initializer and generates the single exported
 `JNI_OnLoad` plus the concrete `android-view` registration callback. The
-function returns the application state, whose `AndroidAppState::Resources`
+simple form mutates `AndroidUiState` through a reference. An application with
+custom state returns that state instead, and its `AndroidAppState::Resources`
 associated type selects the resource bundle. `StdRsc` is the default, never a
 host requirement; a custom bundle works by implementing the narrow
 `AndroidResources` capabilities.
+`AndroidUiState` and `DesktopUiState` implement their own host-state traits,
+so an application with no additional fields uses them directly. Desktop takes
+the widget-building initializer through `DesktopApp::run_with`; custom state
+types retain the lifecycle trait hooks and derive their host-state accessors.
+Background work crosses back to either UI thread through `TaskCtx::update`.
+Each update wakes the host, Iris applies all queued closures, and the retained
+tree's existing dirty-state check requests a frame only when a root, layout, or
+widget changed. Winit's user-event proxy and Android's posted callback are
+private implementations of that wake; applications do not define platform
+event types or manually request redraws.
 
 `cargo-iris` is an installable Cargo subcommand, rather than a script callers
 must find inside an Iris checkout. `cargo iris apk` builds the Rust `cdylib`