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.

You said "iCloud" and "data limit" but the services under the umbrella and those terms are all different based on the tags (across two different services). It really boils down to what the user is doing, what service you are using, and what your system looks like: If they are creating / managing a document: let them know what is happening and allow only local saves until resolved or a specific amount of free space opens; you can take an existing cloud-based document and move it to a cache so to prevent data loss or just store it locally. UIDocument and its lifecycle is pretty rich with error handling so there's a lot of opportunity to handle this situation. If you are using CloudKit, there are different options based on what you are doing and what you mean. If the user has run out of space, you should tell them and then either cache changes locally (to push up when done), treat the situation as if the user has logged out, or just prevent edits if there's no local store mechanism in place. If your app has hit a data transfer/requests quota, you have larger foundational development problems with your CloudKit mechanism and you should look at addressing those problems (I haven't yet, in two years with many many users, hit my apps CK quota). There is no way to donate data to the user, this is a situation in which they need to resolve and the good news is that the system will be prompting them all over outside of our app. Ideally, you'd let them know once per session, what the app is doing until that problem is resolved, and continue to let their interaction move forward.