Also seeing this regression on iOS 18.0—I haven't tested other versions yet.

I hate to lift this out of the 7 year cold storage—but has there been any sort of progress on this issue? Also seeing layouts that can't scroll horizontally, and applying the patch suggested (replacing the width in the setFrameSize of Collection View) hasn't turned out to be the most stable (occasionally, I am seeing a layout loop that eventually crashes the app).

I am also struggling with this as well and can't find anything in the docs related to lightweight migration. They say "The code to import this data is separate from the functionality provided by Core Data. The execution of this import is interposed between migrations."

State shouldn't be directly accessed outside of the view that they’re declared in (unless passed to a subview) and it’s actually best to declare them private—as you can see, trying to access it outside of the view hierarchy in causes some unexpected behavior. As an alternative, you can pass in an observable object which holds the state outside of the view safely, and instead update and check a variable on that for the value.

set the staleDate and check in your view if data is stale It's not documented anywhere, but staleDate has a minimum of 2 minutes from the activities start. So if you set a date any time before that, it won't fire for at least 120 seconds.

Also interested in this… viewthatfits is the only trick I’ve in mind

The UI is actually not updating based on individual states being consumed through timeline refreshes, but instead set to an "end state" through which the middle-states are being interoperated. For example, to display a countdown you can use Text(_:style) with a relative style which would result in a the view remaining up-to-date outside of timeline momentum. In this way, the only cases you need to refresh the timeline would be to add, remove, or replace the widget's countdown end date.

Has anyone found a solution to getting the contents pinned into the top left that doesn't require embedding two ScrollViews within each other like this? The problem with this solution is scrolling becomes "locked" to a single direction depending on whichever ScrollView captured the event first. So if scrolling horizontally, you must release the scroll, let it complete, then you are free to scroll vertically. The scroll view area loses diagonal scrolling as well.

Bump :)

You can find the information you are looking using the CKRecordZone.ID and a little bit of logic! Since the Zone ID contains the owner name, you can just compare that to the active user (CKCurrentUserDefaultName) to see if we are writing into our own database or someone else’s (since users can’t create zones in other user’s databases, that means if we don’t own it we are targeting the sharedDB). I generally recommend to treat the CKRecordZone.ID as just as critical information alongside of the CKRecord’s metadata, even if you aren’t using multiple databases, since without it you lose the ability to accurately target records if you are to expand into multiple zones/databases in the future — I go as far as tombstoning this information along with the CKRecord.ID after local deletion since it can become a nightmare to deal with offline/failed deletes without it.

Thanks for the workaround!

Ditto that - tried to manually remove the .pref and reinstall without any luck here. Same errors as reported.

The best way to go about this is to schedule a local notification to trigger whenever the timer is set to expire. When your application is about to move into the background, calculate a timestamp based on the current time and time left, schedule the notification, and then stop all work in your application related to the countdown (like UI loops or any other in-app work). If the user leaves the app or locks the phone, they will receive a notification at that time to bring them back into the app. When your app moves back into the foreground, update your your based on the current time: if any of their timers expired, show the UI as completed; if not, start a new loop to manage the countdown UI from the current point with the time left. Unfortunately iOS will not give you enough time running in the background to keep a timer active. You get a few moments to do clean up work (like what I mention above) but nothing more — even attempting to request more time from the system will not give you the length you are looking for… and if you keep doing work too long in the background, iOS will terminate just your application. Ideally, unless you are updating the UI on screen (like a visual countdown), you shouldn’t be running an ongoing task like this— it’s better to schedule these events out ahead of time: there’s much less work for the system to do and much less for you to manage this way. Using notifications you can get several customizations to help integrate with system features like Wind Down and some even more interesting ones in iOS 15 — you can’t get something exactly like clock which is a part of the system, but you CAN get something good!

Same here :(

You are my heroes! Though I can't get it to build on device with this set, it's nice to be able to at least use Previews (and simulator) when I'm working.