[Nutcasey]

Part 1 of 6 splitting #2621. Review commits 91a5ba00 (Trends) and e6136415 (what came across from Statistics).

Trends is a review of one period at a time: a day, 7, 14, 30 or 90 days.

• Summary tiles: average glucose with SD and CV, GMI, insulin, carbs and boluses per day, and how long Loop was closed loop.
• Cards: time in range, the daily pattern (AGP), basal and bolus, insulin per day, and Loop status with a list of its gaps.
• One day: a one-day period leads with that day's timeline.
• Drill-down: tapping a day opens a day page with the insulin timeline and active insulin and carbs, stepping a day at a time.
• Export: a PDF report, or a CSV with one row per day.

Inside Loop's 7 days the figures come from Loop's own stores, so manual and automatic boluses, temp basals, historical targets and presets are known. Older days come from Apple Health. Closed and open loop are recorded from launch, because LoopDataManager.automationHistory keeps only 36 hours.

Where it opens. Before the home screen changes, Trends opens from Settings → Trends, beside Statistics, as a sheet with its own navigation and a Done button. Statistics and Current Setup are unchanged. A pushed screen didn't work here: navigationDestination does nothing inside Settings' NavigationView, so the day page and Gaps wouldn't open.

Screenshots are from #2621, where Trends is a tab. Here the same screen opens from Settings with a Done button.

What came across from Statistics

Trends and Statistics answer the same question, so the second commit (e6136415) brings into Trends everything Statistics shows that Trends lacked. Trends already had the 7/14/30/90-day ranges, GMI, average, CV, CGM active, time in range, the daily pattern and daily insulin with its basal, bolus and automatic split.

On Statistics	Now on Trends
"Goal:" under GMI (<7%), Average (<154 mg/dL), Variability (≤36%) and CGM Active (>70%)	One "Aim:" line under the summary tiles: average under 8.6 mmol/L (154 mg/dL), GMI under 7%, CV 36% or less. CGM active over 70% is on the Time in range card, beside its figure.
Time in range goals: in range >70%, above <25%, below <4%, very high <5%, very low <1%	The Time in range card's "Aim:" line carries all five.
"Usually X U by HH:MM" under Today	Under "Total so far" on today's Day view, and under the Insulin per day chart on longer periods ending today. Same InsulinDeliveryHistory.typicalDelivery, so the same figure.
"· scheduled X U" beside average basal	"Scheduled X U" under Basal in Basal and bolus: the schedule that applied (stored profile with presets), or today's schedule where the profile history doesn't reach.
"Showing N days of data…" when the period isn't full	"CGM data covers N of M days." under Summary.
Fingerstick (user-entered) readings left out of the figures	Left out of every Trends figure too. The day timeline still draws them.

Not carried over: "This device keeps N days of glucose. Increase the cache duration…" (Trends reads older days from Apple Health, so the local cache doesn't limit it), and the two helper lines "Each 5% increase in range is clinically beneficial" and "Each 1% time in range ≈ 15 minutes" (Trends shows each band's hours a day).

On the same 14 days of simulator data, GMI, average, CV, CGM active, "usually by now" and scheduled basal match Statistics exactly. Statistics is still in Settings in this part so the two can be compared side by side. Once you're happy Trends covers it, removing Statistics is a small follow-up.

Differences from #2621

• Ported to Use LoopKit's value types and bridge to LoopAlgorithm #2635's split between LoopKit and LoopAlgorithm types. The IOB and COB timelines for the day page convert with algorithmSchedule() and .loopKit, as LoopDataManager does.
• Trends and the day page's timeline card (DayTimelineCard, DayTotalsTiles) live in DayDetailView.swift, not NowScreen.swift, because Trends needs them before Now exists.
• TrendsView takes an optional done closure for the Settings sheet.
• The Loop status footnotes say closed and open loop are recorded "from when this version of Loop first ran" rather than "from when the new interface was first opened". Recording starts at launch whatever the interface. The two strings have new translations.
• Review fixes: the provider caches the start of Loop's dose records only once it has found one. Before, a day viewed before any records could cache "none" for five minutes, and later days then lost the programmed-rate basal fill. Also removes the unused RangeBand.name/thresholds and Summary.loopCoverageStart.

Testing

On the loop simulator (iOS 27.0, Pump and CGM Simulators, 90 days of history), driven through XCUITest:

• Settings → Trends sheet → Day → today's card → day page → previous day → back.
• 14 days → Gaps → back. Export → CSV and PDF share sheets. 90 days. Done returns to Settings.
• Swiping the sheet down also returns to Settings.
• The Statistics additions: 14 days, today's and yesterday's Day view, and a 90-day period where readings start late. GMI, average, CV, CGM active, usual-by-now and scheduled basal checked against Statistics on the same data.

LoopTests (448 run on this part, on next-dev 5ee95cc6): all pass except BolusEntryViewModelTests.testCarbEntryDateAndAbsorptionTimeString and …String2, which fail the same way on plain next-dev ("12:00 PM" against "12:00"). Xcode's hosted test run stalls at test-host launch on this machine, so these ran in the app bundle under Xcode's simulator XCTest agent, with next-dev's test classes except the HealthKit-hosted DeviceDataManagerTests. Every part was built on its own, in order, on the loop simulator.

The series

#2621 is split into six PRs, in the order Pete suggested: statistics and Trends first, then the Logbook, then the home screen. Add carbs, the widget and Live Activity, and the appearance options follow as their own parts. Each part builds on the one before it and targets next-dev (5ee95cc6, after #2635), so a PR shows the earlier parts' commits too. Review only the last commit of each PR (part 1 has two: Trends, then what came across from Statistics). #2621 stays open as the combined reference until the series lands.

1. [1/6] Add a Trends screen for glucose, insulin and Loop status #2637 Trends, opened from Settings
2. [2/6] Add a Logbook of the last 7 days #2638 Logbook, opened from Settings
3. [3/6] Add the Now home screen with Now, Trends, Logbook and Settings tabs #2639 Now home screen with Now, Trends, Logbook and Settings tabs, and the New Interface toggle
4. [4/6] Rebuild Add carbs around a live preview of the meal #2640 Redesigned Add carbs
5. [5/6] Restyle the widget, Dynamic Island and Live Activity for the new interface #2641 Widget, Dynamic Island and Live Activity
6. [6/6] Add Day and Night app icons and an appearance setting #2642 Day and Night app icons and the appearance setting

The six parts together match #2621 apart from the changes listed under "Differences from #2621" in each part.

Merging. Merged in order with merge commits, all six apply cleanly. With squash merges, each next PR needs a rebase onto next-dev once the previous one lands, because it still carries the earlier part's original commit. I've checked that every one of those rebases applies cleanly and that the end result is identical to part 6. I'll rebase each PR as the one before it merges.

Strings. Each part adds only its own catalogue entries, with their translations in Loop's languages, and fills in translations for the existing keys it starts using. GitHub's line diff of Localizable.xcstrings can show deletions where Xcode's ordering interleaves new keys. Parsed as JSON, no part removes or rewrites any existing entry.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH

[ps2]

Thanks for splitting this up. Trends reads well and the Statistics parity work is careful. Before this goes further I'd like to shrink it and remove the overlap with Statistics.

Replace Statistics. Trends should replace Statistics in this PR rather than sit beside it in Settings. Two screens answering the same question will confuse people, and the parity commit already covers what Statistics shows. Please remove the Statistics entry and the screen as part of this change.

Duplicated figures. Several numbers appear two or three times on one page:

• Insulin per day and the basal/bolus split are in the Summary tile, the Basal and bolus card, and the Insulin per day chart's average line and legend. Could Summary stay focused on glucose (plus carbs and boluses), and Basal and bolus fold into the Insulin per day card, with Scheduled and Manual/Automatic under the chart?
• Loop active in Summary repeats the Loop status card, and it covers a different window from the period's other figures. It's clearer only in Loop status, beside its coverage note.
• "Usually X U by HH:MM" appears twice. One place is enough.

Aim lines. The Aim sentences, especially the six-target one under Time in range, are hard to scan. Showing each band's target in its row, or marking a figure that misses its target, would say the same with less text.

Colors. The PR adds 17 named colors, and most could reuse what Loop already has. glucose-ink, accent-ink, insulin-ink, bolus and carbs-ink are variants of the existing glucose, accent, insulin and carbs colors. agp-inner, agp-outer, target-band, basal and basal-edge can be those colors at reduced opacity, with no new color sets. ink-muted can be .secondary. The five range-* colors duplicate GlucoseBand.agpColor in Statistics (TimeInRangeBar.swift). Since Trends replaces Statistics, keep one time-in-range palette; your dark-mode variants are an improvement, so move them there. control-thumb goes away with a system segmented Picker.

Scope. Could the day page, Gaps and Export come as follow-up parts? Export in particular produces a shareable, clinical-looking report that deserves its own review.

Open/closed loop history. Loop keeps 90 days of data (Bundle.main.localCacheDuration, LOOP_LOCAL_CACHE_DURATION_DAYS), and localHistoryStart already uses it. Rather than a new UserDefaults record (LoopModeHistory, 100 days), please read closed/open loop from data Loop already stores. StoredSettings carries dosingEnabled with a date, and SettingsStore keeps those records for the cache duration. The provider already uses getStoredSettings for target history. If that doesn't work out, a new record should follow the other stores' design (Core Data in the cache store, expiring with localCacheDuration) rather than live in UserDefaults.standard. It's also worth checking that every closed-loop toggle path saves settings, so the history isn't missing changes.

"Loop keeps 7 days". Two strings hard-code this: the Loop status footnote and the day page's Apple Health note. The provider's window is localHistoryStart, which is the cache duration, 90 days by default, so the text is wrong for most builds. It should follow the cache duration rather than hard-code a number.

Older periods. For days beyond Loop's local history, how does the screen show that the Manual/Automatic split and the scheduled basal are partial or estimated?