Live Activities: API gaps for ProgressView, Text(timerInterval:), and compact/minimal icons
Thanks for organizing a session on Live Activities — looking forward to it. We're shipping a Live Activity for train departures (a countdown to departure, plus a custom indicator for the platform the train leaves from), and we've run into a handful of limitations where the public API doesn't seem to expose behavior that first-party experiences appear to have. We'd love either guidance on how to achieve these today, or confirmation that they're on the roadmap. Grouping them by API below.
ProgressView
1. Height isn't adjustable. (FB23091027) A linear ProgressView renders at a fixed height. The only lever we've found is scaleEffect, but scaling the whole view also scales the corner radius, so the rounded caps end up distorted (stretched ovals instead of clean pills). We'd like a supported way to set the bar's height — or at least a fixed-radius style that survives scaling.
2. Only the fill is stylable, not the track. (FB23091058) .tint(...) and progress view styles let us color the progress portion, but we can't find a way to style the background/remaining track (color, opacity, etc.). First-party progress bars clearly have a styled track, so we assume there's a path we're missing.
3. No separator/border between filled and remaining. (FB23091078) We'd like a visible border or divider at the boundary between the active (filled) and remaining segments. There's currently no hook for this without abandoning ProgressView entirely and hand-rolling the bar.
4. ProgressView(value:) carries extra vertical padding that ProgressView(timerInterval:) doesn't. (FB23091242) The value-based initializer renders with an additional ~3 pt of top/bottom padding that the timerInterval: initializer doesn't apply. When the two are placed together — or swapped for one another — their bars don't line up vertically, since one has extra vertical inset and the other doesn't. We'd like the vertical insets to be consistent across the two initializers (or a supported way to control them) so progress bars can be aligned reliably.
Collectively, points 1–4 push us toward reimplementing the progress bar with Canvas/Shape, which feels like it shouldn't be necessary for something the system already draws.
Text(timerInterval:)
5. No minute-granularity ("3 min.") countdown. (FB23091094) We want a self-updating timer that ticks down in whole minutes — "3 min." → "2 min." → "1 min." — rather than MM:SS. Apple already does this: in the Dynamic Island compact trailing region, the system Timer renders a coarse, minute-granularity countdown that updates itself (it shows e.g. "3 m"). We'd love exactly that, but with a localizable, slightly longer unit such as "3 min.". Today Text(timerInterval:countsDown:) only gives us the full digit-ticking format, and we can't find a supported way to drive a minute-granularity self-updating timer.
6. It always reserves full horizontal width. (FB23091111) A Text(timerInterval:) claims the maximum horizontal space its widest value would need (presumably to avoid layout jitter as digits change). Concretely: placing a Text(timerInterval:countsDown:) in compactTrailing stretches the Live Activity to fill that direction. Apple's own Timer doesn't do this — its countdown in the same compact trailing region hugs its content. We'd like a supported way to opt into that content-hugging layout, accepting the jitter trade-off ourselves.
Compact Dynamic Island
7. Animating between two icons while the timer stays visible. (FB23091159) In the compact presentation we want to transition between two graphics on a state change — in our case, cross-fading between a vehicle/line glyph and our custom platform indicator (showing which platform the train departs from) in the compact leading slot, while the departure countdown stays visible in the trailing slot. Today the swap hard-cuts. First-party activities show smooth content transitions in these regions, so we assume there's a supported approach we're missing. Guidance on supported transitions for the compact slots would be very welcome.
If any of these are already achievable, we'd genuinely appreciate pointers — we may simply be holding the API wrong. And if they aren't, consider this a consolidated feature request. We've filed each as an individual Feedback item (FB numbers inline above) and are happy to attach sample projects and screen recordings.
