Widgets & Live Activities Q&A

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.

From post https://developer.apple.com/forums/thread/778914 I am wondering if there is any news on https://feedbackassistant.apple.com/feedback/17148295

I have widgets on iPhone and Watch. It uses colors and color gradients to convey information to my users. I respect Differentiate Without Color, but what has been defeating me is colored screens on watch and phone when it desaturates the widget. The view is not legible any longer. What would you recommend for handling my views. I would be happy if I could show the textures I made for Differentiate Without Color, and I tried, but the screen color tint seems to fill the entire frame. How do I control this? Once it is controlled, what are my options for display? Any other suggestions?

Hi, do you have suggestions for implementing widgets that get populated with data from external sources at different times? Example: a few numbers are displayed that usually update once or twice a day but some days multiple times per hour for part of the day. We can't get this to work reliably on all of the devices we are testing with and because the throttling/budgeting behavior is opaque it is more of a challenge to pinpoint why. Here are some things we are starting to experiment with, it would be helpful to know if some or all of these approaches would be too demanding of resources to be useful when populating widgets with content: creating dynamic timelines that have different frequencies on different days in the main app downloading new schedules from a server for the timelines for future dates using a combination of silent push notifications and background tasks to download the data when notifications are missed And we're already aware of the basic guidelines (relaxed budget constraints when debugging from xcode, avoid force quitting apps, etc.), would be great to get additional insight beyond the documentation like how to tell when an app has already depleted its budgets. Thanks again!

If the user has a lot of widgets the timeline generator can wind up getting killed. Is there any recommendations on how to deal with this? Is there for example any equivalent of applicationDidReceiveMemoryWarning() ?