UI direction: adaptive light/dark theme — would a Goose-style design language work for NOOP?

[tigercraft4]

Hey @NoopApp — wanted to open a conversation about UI direction, specifically whether a system-adaptive design language (light + dark) could work as the app grows.

Context

NOOP currently runs a fixed dark theme. That works well for a glanceable utility, but as more screens land (trends, sleep, health sources, workouts) a proper light/dark adaptive theme might scale better and feel more native — especially on iOS where most health apps follow the system appearance.

For reference, here's what the same WHOOP data looks like in a similar project that ships both modes with the same 4-tab structure:

Light mode

Home	Health	Coach	More

Dark mode

Home	Health	Coach	More

Card-based layout, coloured metric rings, clear section hierarchy — same data, different visual weight depending on the system setting. Both modes share the same component library; the palette just flips with @Environment(\.colorScheme).

What I'm not suggesting

A full redesign or breaking change. The underlying screens (Today, Sleep, Live, Trends) already exist. It could be a pure visual layer — swap the palette to follow the system appearance, keep the layout as-is.

Questions for the community

• Does the fixed dark theme feel right long-term, or does it start to feel limiting as more screens get added?
• Would a system-adaptive theme (light + dark) be worth a milestone?
• Is there a preference for one mode over the other as the primary?

Tagging @NoopApp since this touches the core visual identity — curious what the thinking is, and whether this is something the project is open to exploring.

[NoopApp]

Thanks @tigercraft4 — genuinely thoughtful framing, and "a pure visual layer, keep the layout" is the right way to think about it. A few honest reactions:

• The fixed dark theme is deliberate right now — NOOP started as a glanceable, quiet-instrument utility (recovery ring, live HR, menu-bar/widget) where dark reads well and matches the feel. So it's a choice, not an oversight.
• You're right, though, that as the screen count grows, a system-adaptive light/dark could feel more native — especially on iOS where most health apps follow the system appearance.
• The honest caveat: it's a bit more than a palette flip. NOOP's design system is already built on semantic colour tokens, so following the system appearance is very doable — but every surface (the recovery ring, charts, sparklines, the green/amber/red status bands) needs checking for contrast and legibility in light mode. We'd want it to look genuinely good, not just inverted — so it's real design work, not a switch.

It's firmly on the "would seriously consider" list, and this is exactly the kind of input that shapes it. Keeping the conversation open — curious what others think, and the maintainer may want to weigh in directly since theme is core to the app's identity. 🙏

[tigercraft4]

Taking this one step further — I'd actually be open to contributing the UI from my personal app as a starting point for NOOP's redesign.

It already ships adaptive light/dark (the screenshots in the original post are from it), uses the same 4-tab structure, and displays the same WHOOP data. The idea would be to port that visual layer into NOOP — keep all the existing logic and data models intact, just replace the UI with one that already handles both modes properly.

It's more than a palette swap, but less than a ground-up redesign since the component structure and colour tokens are already worked out. Happy to open a draft PR with the port if that's something worth exploring.

[NoopApp]

Really glad you raised design direction — worth talking about openly. Let me be straight about where things are.

Today NOOP is dark-only, on purpose — and it's enforced, not an oversight. Every semantic colour (near-black surfaces, the health-green accent, the recovery traffic-light gradient, strain ember→magenta, sleep indigos) is a hand-tuned value chosen to glow on near-black, like an instrument cluster. That's the feel NOOP is going for.

On adaptive light/dark specifically — the honest engineering picture: because the whole system is one fixed palette mirrored across Mac (Swift) and Android (Kotlin), a real light mode isn't a switch — it's a second complete palette, designed (not auto-inverted — inverting these would look muddy and the gradients fall apart), then maintained in lockstep forever. For a solo, community-funded project that's a real ongoing tax on every future screen, so I won't promise something I can't sustain.

Where I'd genuinely like your input:

• "Goose-style" is interesting — can you point at the specific qualities you mean? Lighter surfaces? Typography? Whitespace? "Light/dark" and "Goose-style" might be two separate asks.
• If the real pain is glare / daylight readability, there may be a lighter-weight win than a full light theme — a higher-contrast or brightness-tuned dark variant — that I could do without forking the whole system.
• If there's real appetite for a true light mode, the right first step is one fully-resolved light screen as a design study before committing the whole app.

Dark-only is a deliberate identity choice I'm protective of, but I'm not closed to evolving it — tell me what specifically pulls you toward Goose and what problem light mode would solve for you.

[tigercraft4]

Thanks for the honest breakdown — the engineering reality makes sense, and I don't want to pitch something I'd abandon after one PR.

To be specific about what I mean by "Goose-style":

• Card hierarchy and whitespace — the current NOOP layout packs a lot of information into tiles without much breathing room. The thing that reads well in the reference screenshots isn't the light surface, it's the grouping: metrics collected into clearly bounded cards with a consistent internal rhythm. That structure works in dark mode too.
• Coloured rings with prominence — the recovery ring in the screenshots gets more visual real estate and more contrast against the surrounding card. Same data, but the eye goes there first.
• Section headers with weight — the dashboard feels scannable because each section has a typographic anchor. Again, not a light-mode thing.

So to answer directly: light/dark adaptivity is secondary. The specific qualities I'm pointing at are layout density, card grouping, and ring prominence — all of which could work on a dark palette.

On the daylight readability question — yes, that's a real factor on iOS in particular, but you're right that it's a separate problem from the layout language. A well-contrasted dark variant would address it without forking the palette.

On the "one fully-resolved screen as a design study" — that's the right frame. My offer to contribute the port stands if it's useful, but happy to start smaller: I could put together a single screen mockup (Today/Home) that translates the layout language onto NOOP's existing dark palette, no light mode involved. That would make the conversation concrete without committing to anything.

Would that kind of design study be worth opening as a draft PR or issue?

[NoopApp]

That's exactly the right reframing — thank you for being so precise about it. Pulling layout language apart from light/dark is the unlock here, and you've landed on the three things that genuinely read well in those reference shots: card grouping with consistent internal rhythm, ring prominence, and weighted section headers. All three live on the dark palette. None of them require forking it.

And good news on feasibility: those primitives already exist in NOOP's design system — there's a card component, a section-header style, and the recovery ring is its own view. So this is re-composition on the existing tokens, not a rewrite. That's the kind of change I can actually sustain.

So yes — a single Today/Home design study, on NOOP's current dark palette, no light mode, is the right first step, and I'd welcome it. A couple of things to keep it productive:

• Open it as a draft (PR or even just static mockups in the thread — whichever's lighter for you). The point is to make the layout language concrete and look at it side-by-side with what's there now, not to merge a port. I review external contributions carefully and tend to re-implement rather than wholesale-swap, so treating this as a study keeps both of us honest about scope.
• Use NOOP's own tokens/components rather than bringing your app's component library across — same reason. If the grouping/rhythm reads well, the win is in how the existing pieces are arranged, and that's portable without dragging a second system in.
• Stay on the existing dark surfaces and accents for this round. If the layout lands, we'll have a clean basis to then talk about the daylight-readability problem separately (a higher-contrast dark variant is the lighter-weight path I'd reach for before a full light theme).

To be clear on the bigger ask: a true system-adaptive light mode is still "would seriously consider, not committed" — it's a second hand-tuned palette maintained in lockstep across Mac and Android forever, and I won't promise what I can't sustain. But the layout study has nothing to do with that, and I'm genuinely keen to see it. Tag me when it's up. 🙏

[NoopApp]

Thanks for this — it's a thoughtful thread and we've genuinely chewed on it. Where it stands:

We explored an adaptive light/dark direction and put together a light-mode study to see how NOOP's palette translates. The conclusion for now: NOOP's dark, deep-green identity stays the default — it's core to the app's character and it's what the whole component system is tuned for. A proper light theme is a real design effort (every chart, gauge, gradient and state colour has to be re-derived to read well on light), so rather than ship a half-converted theme we'd rather do it deliberately when we take it on.

So: not a no, but a "not rushed." We're tracking it as a design-direction item. Closing the discussion to keep the board tidy, but the input here directly informs how we'd approach it — appreciate you pushing on it.