It is a single shared amount of memory for all your widgets, and it is exceptionally annoying. That limit has been a thorn in my side since the introduction of widgets. I have a bunch of different widgets at all the sizes and locations and each is highly customizable and for some people it just won’t work because of that arbitrary limit, which has not been updated at all as phones have gotten more powerful and widgets are expected to do more and more.

First, you are in a losing battle using the things Apple does to gage what it is possible for you to do. It is not realistically possible to duplicate the clock widgets within the limits that are provided for 3rd party widgets. Apple has granted their own widgets special permissions. It is possible to add a timeline entry for each minute, but you have to hit a balance between overrunning memory limits (30MB as far as I can tell) and limiting the number of refreshes. Timeline entries will show at exactly the time you specify, but the same is not true for refreshes. You are able to tell the system when to refresh, but they don't provide any sort of guarantee as to when the refresh will actually happen. In your example created 30 minutes of entries and then said to update at the end of those 30 minutes. It didn't actually do the refresh for another 15 minutes. You are going to run into trouble doing a refresh more than once per hour, but I am not sure that is even a sure thing. Regardless of how often you do the refresh, if you want timing precision, you need specify the refresh at a particular time and then have the timeline entries to go past the refresh time. As an example (that may or may not be good numbers), you generate 2 hours worth of timeline entries and then set the refresh to happen every hour.

I don't have anything helpful to say here, but would like to say that I 100% agree with this. I would go so far to say that any of the features that result in Apple holding on to state for our apps should provide us a way of migrating that data as needed. Widgets and Shortcuts both result in Apple holding on to data for the user that is directly tied to our app's code, but is completely outside of our control. What this effectively means is that we either have to be locked in to choices made years ago despite the entire system changing around us or completely break things for our users and force them to fix it on their own. We added widgets to our app back when they were new (2020) and widgets as a whole looked very different. They were iPhone only, only on Springboard, and only appeared in fully color. None of that is true anymore and I would make different decisions about what widgets we would provide, how they are organized, and how they are configured. This might be the year that we do finally change everything, but it will come with a bad user experience because I can't do anything about their installed widgets. Those widgets will break or disappear completely and there is nothing I can do about that. I would love something similar to what was added a year or two ago for migrating watch complications from ClockKit to WidgetKit. If I could provide some migration code to convert existing saved widget configuration to a new configuration, it would fix so many issues.

It is not possible to surface pin in the simulator. I confirmed this with Apple engineers in a WidgetKit Lab during WWDC25. However, as far as I can tell, that doesn’t actually make any functional difference to the widget itself, you just can’t see it in that frame

Like many things in Apple’s widgets, they are doing things we don’t have access to. If there is a way to do what you are looking for, I would love to know what it is, but based on my testing there is literally no way to make text be any color other that white or the accent color with some level of opacity. On top of that, the Widget views have no way of knowing what the accent color is so there is no way to adjust based on having a light or dark accent color. Our inability to really layer things and maintain readibility is one of the many shortcomings in the tinted widget system that came out this year

The today widgets have been deprecated for years. I believe that was done in 2020 when they introduced the new style of widgets, but maybe it was a year later. With iOS 18, the Today Extension Widgets are being completely removed. You can keep them in your app for the benefit of iOS 17 or older users, but there is no option to support them on iOS 18. Any widgets should be implemented using WidgetKit

It isn’t covered because it isn‘t a new mode. It is just new to the Home Screen. The answer to your question depends on which thing you are referring to. if you need to know in your code that you are in the tinted mode, to choose a different image for instance, you can check the widgetRenderingMode environment variable when it is in the tinted mode, this should be accented if you are specifically asking about how to color something in the accent color, you just need to add the widgetAccentable() modifier to what ever view you want to take on the accent color

What you are trying to do is not possible and not how the mentioned methods are intended to work. when you interact with a widget, your app intent will be called and when that intent finishes the perform method your widget will get one guaranteed reload that will happen immediately. There is no way for it to update the widget multiple times. note That even that one update only applies to the widget that was interacted with. If you have multiple widgets, they may or may not get updated automatically. Calls to reloadAllTimelines is always a suggestion to the system and should never be expected to immediately refresh the widgets. Apple has never really documented what the algorithm is here, but things like how often you are refreshing the widget, how often the user is using your app, and the systems battery power seem to play a role in that decision.

There is nothing you can do because that is not how the widget update system works at all. Any request to update the widgets is a suggestion and the system will schedule the update as it wants. The only way to get your widget to change at an exact time is to schedule a timeline entry for that time, but that requires knowing what it will look like in advance. Notice that the policy you are using is “after” and not “at”. It is telling the system to wait until at least the specified time.

The time when a particular timeline entry is show is 100% controlled by the date field in your TimelineEntry. I can think of two possible things they might be going on. One is that you aren’t actually providing all the timeline entries you think you are. The second, and more likely, possibility is that you aren’t being specific enough with your time. If you generate timeline entries on Monday at 2pm create the first entry at the current time and then just add 1 day to get the Tuesday entry, the actual time will end up at Tuesday at 2pm which is when it will change. If you want it to show correctly you need to make sure the time is zeroed out to midnight For your entries.

You are 100% right that the timer text field desperately needs formatting controls. I could delete a massive amount of code if it would just stop including the seconds field. As to your problem, keep in mind that since you have no control over when the timeline generation code runs, it is almost certainly not happening right on a minute mark. Before you start generating your timeline entries take “now” and remove the seconds part of the time. the easiest way to do this is break the date into components and then rebuild it with the seconds hard-coded to zero. Start with that date and continue on. That will make all of the timeline entries at exactly the minute mark

What you have above is invalid, because you are trying to make two different widget definitions with the same “kind”. That value serves as the unique identifier for a widget definition. For a single given widget, they cannot have differences between configuration options at the various sizes (much to my own frustration). The only way to do what you are trying to do is make one widget for small/medium and a different widget for large (which means specifying a different ”kind”. The two different widgets can share a name and description so they sort of look like the same widget but there are a number of places that that it will be obvious they are split

There is no way to do that by design. If a user has multiple copies of a widget with matching configurations, I think Apple uses the same timeline to feed those multiple widgets.

The thing you want to do is possible using disfavoredLocations(for:). https://developer.apple.com/documentation/swiftui/widgetconfiguration/disfavoredlocations(_:for:)

That seems like it should work. I am using a very similar form without problem and I am deploying back to iOS 15 extension View { func widgetBackground(_ color: Color) -> some View { if #available(iOSApplicationExtension 17.0, macOSApplicationExtension 14.0, *) { return containerBackground(color, for: .widget) } else { return background(color) } } }