[vishk23]

The sky branch in LiquidTodayView is commented:

Reduce-motion (and low-power) users get the same sky posed still — no twinkle/breath.

but isLowPowerModeEnabled appears nowhere in the UI — the only hit in the whole tree is Strand/System/IOSDiagnostics.swift, where it is reported, not acted on. The low-power half was never implemented. This implements it, for the sky and for the three live primitives (LiquidVessel, LiquidTube, LiquidThread), reusing the exact static render path that Reduce Motion already routes to.

There is no SwiftUI environment key for Low Power Mode, so LiquidPowerMonitor observes .NSProcessInfoPowerStateDidChange and publishes it; toggling the setting takes effect without a relaunch.

Why it is worth doing

A continuously-animating Canvas is not free. Measured on an iPhone 17 Pro simulator seeded with a real 746 MB store, default Today screen sitting idle with no touch input — three 15 s CPU windows after a 45 s settle, machine otherwise quiet:

build	live gauges	posed still
Debug	18.4 / 19.3 / 18.3 % of one core, 311 MB RSS	0.0 / 0.0 / 0.0 %, 290 MB
Release	18.2 / 18.7 % of one core, 298 MB RSS	0.0 / 0.0 / 0.0 %, 226 MB

The animation is the entire idle cost of that screen. Notably it is the same in Debug and Release, because the per-frame work is GraphicsContext drawing rather than Swift arithmetic — optimizing the Swift only moves the smaller half (a standalone -Onone vs -O benchmark of the liquidWave / fleck math gives 0.614 → 0.100 ms per hero-gauge frame, which is real but is not what dominates the frame).

Low Power Mode is the user explicitly asking the system to stop this class of work, so honouring it costs nothing when it is off and saves ~18% of a core when it is on.

No behaviour change when Low Power Mode is off

Re-measured after the change, not in Low Power Mode: 19.7 / 19.5 / 20.1 % of one core — still animating, unchanged within noise. Screenshotted the Today screen after the change: gauges, sky, and all card surfaces render identically.

Scope note

I could not toggle real Low Power Mode in the simulator, so the "posed still" column above is the Reduce Motion route — which is the same staticGauge / staticTube / staticThread / LiquidSkyStatic branch this change sends low-power users down. The new condition is animated && !reduceMotion && !power.isLowPower, so the saving is the measured one; what is inferred rather than directly exercised is only that iOS reports the flag, which IOSDiagnostics already relies on.

[ryanbr]

Checked the claims rather than taking them, and the completeness question this kind of change usually fails on.

Verified

The premise is exactly right. isLowPowerModeEnabled occurs once in the whole tree, at IOSDiagnostics.swift:45, where it is reported and never read. The comment on the sky branch has been describing behaviour that was never wired.

Coverage is complete, which is the part worth checking. LiquidSky( has exactly one call site and this gates it. More to the point, there is no other TimelineView(.animation…) anywhere in Strand/, StrandiOS* or NOOPWatch* — the four surfaces here are all of them, so nothing keeps animating behind the fix.

No mid-animation glitch. staticGauge renders LiquidSim.posed(value ?? 0) rather than the live sim, so flipping Low Power Mode during a splash snaps to the correct posed picture instead of freezing a transient frame. That is the obvious way this change could look wrong and it does not.

The concurrency shape is fine here. @MainActor singleton with MainActor.assumeIsolated inside a queue: .main observer would be worth arguing about under Swift 6, but the target is SWIFT_VERSION 5.0 with SWIFT_STRICT_CONCURRENCY: minimal, so it compiles and the block genuinely runs on the main thread.

The measurement caveat is handled honestly — routing through the Reduce Motion branch is legitimate precisely because it is the same branch, and the description says so rather than implying real Low Power Mode was toggled.

Android has the identical gap, and it is bigger

Same shape as #908, which also fixed one platform of a two-platform problem:

surface	mechanism
ui/LiquidSky.kt:276	withFrameNanos frame loop
ui/LiquidPrimitives.kt	withFrameNanos
ui/TimeOfDayBackground.kt:150	rememberInfiniteTransition("atmosphere")

LiquidSky.kt:252 even carries the mirror-image comment — "Under Reduce Motion it collapses to the static picture (no frame loop)" — so Android is half-implemented in exactly the same way, for the same reason.

And the diagnostic parallel holds too: Android touches PowerManager only at AndroidDiagnostics.kt:270, and for isIgnoringBatteryOptimizations, which is a different question entirely (background-work exemption). isPowerSaveMode appears nowhere in the tree. The fix is that flag plus ACTION_POWER_SAVE_MODE_CHANGED for the live half, mapping onto the static branches Reduce Motion already uses.

Not asking for it in this PR — the Apple half stands alone and the saving is real. But it should be a stated follow-up rather than silent, the same way the Android half of #908 was.

One thing to flag about verification

All three files are app-target Swift, and app-build.yml is disabled_manually, so no CI job compiles any of this. The simulator measurement means it built locally, which is the strongest evidence available right now — but a compile-only dispatch of that workflow on this branch would turn "it built on one machine" into a check, and it is the same gap that let a red test sit on main for weeks before android.yml was turned on.