Testing NavigationLink(destination:tag:selection:) on iOS 13 results in behavior that's similar: Selection Occurs, the publisher fires the proper tag. Selection is lost, the publisher fires nil twice So it looks like in iOS 14 we are now getting some sort of weird hybrid behavior. And using .tag on iOS 13 with List selection doesn't work at all so there must have been some work done to try and extend the capabilities.

Bug in SwiftUI lifecycle — Apple acknowledged it in a ticket I put out but that's as far as I've gotten.

ShapeEdit! ShapeEdit!

Have you had any luck here? I'm looking into this as well and from what I can tell, Apple does this very thing when switching between the List and Grid view in Notes.

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.

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.

Same here :(

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!

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

Thanks for the workaround!

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.

Bump :)

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.

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.

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