Post not yet marked as solved
Bug in SwiftUI lifecycle — Apple acknowledged it in a ticket I put out but that's as far as I've gotten.
Post not yet marked as solved
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.
Sounds good to me! Thanks!
Post not yet marked as solved
Ah I totally see what you're saying! Very frustrating.I wish we could get more insight to why this error is being put up. And why CloudKit error is lacking the data to actually resolve it because I'm surely going to hit this issue in the future.I'm really confused because I'm not sure what is actually related to the chain on the parent record, besides its existance. Did you figure that out?
Post not yet marked as solved
Yep, that's essentially the same thing that I am doing and I get no kickback unless I attempt to delete a parent with children, and even in that case I'm provided with a different error under the CKErrorReferenceViolation branch. I even just tested it and am not having issues what-so-ever. Currently using a custom zone in the private container, made using the save method on the privateDB (I assume all capabilities enabled). Using CKModifyRecordsOperation to push my changes to the record, just as you are.Oh, but I did just dig up that I change the default savePolicy property on the Operation! The default CKModifyRecordsOperation.RecordSavePolicy is .ifServerRecordUnchanged but for this type of operation it should probably be set to .changedKeys. Then keys you're not interacting with won't be touched.
Post not yet marked as solved
> Now device number 2 comes along and also creates a record named Drinks but does not have the one on the server yet (obviously). Also device 2 does not create Milk and Juice (or any children for that matter). So device 2 sends its version of Drinks to the server, and I get the server record changed error. How would I handle it? In this case, I'd cache the server records metadata of drinks in my local cache. Later (hopefully soon) I'll get a notification and my fetch zone changes operation will pull down Milk & Juice.My 2 cents is that this error calls for an active & major resolution to ensure the devices are back in sync before waiting on the next fetch to travel down with specific records that need updating. If something happens and you can't get those fetches (CloudKit or device move offline, record changes lost, device termination, etc), it can make resolving your records with a users new changes to the local store a nightmare as they queue on either side. It also can/tends to affect large sets of records.I now assume that the entire local store of relevant objects on device number 2 is entirely out of sync with the cloud records, so instead of trying to resolve it on a scoped single record or record chain basis (Drink, Milk & Juice), I pull down every record in both parent, child record types in the zone and compare, merge them into my current device model with varying degrees of specificity. This helps to avoid records ghosting out on Device 2, while existing on Device 1 and in the cloud. The assumption here being the worst: you'll never get those record changes (changesets have been lost in some way, things have gotten too complex to resolve, or the user is making major conflicts before fetches complete [which sum up the situations when I'd most often experience this error]).From there I split untouched model objects away from those that are new, newer on device, or deleted (aided by a tombstone) and push those changes back into the cloud store. The goal being to resolve all changes in this store in one change cycle. Device 1, 3, 4 receive the updated changes from the Cloud notification or launch fetch changes operation to bring them both to partiy with each other. If one of those devices enters a similar state in the meantime as 2, they can do the same flush, repeating the cycle.Edit, I completely misintpreted your original question: That's (seemingly) bizarre behavior that I'm not getting and can't find information on the net about. When I push a locally created parent record from an object, nil recordChangeTag (which also lacks the CK metadata that exists on its cloud record version and has children records in the cloud) it successfully merges, no fuss. This is one of the first things I tested after I enabled sharing by making sure document titles synced!I definitly do not get a kickback requiring me to pull down the cloud metadata at all.
Post not yet marked as solved
I don't think you need to worry about them leaving the app if you're explicitly giving them an action to perform that can only been done outside of it; they'll come back as long as the task they leave the app for is in the same vein of work and not very complicated. I remember there was once a URL scheme to pop a user into the Account settings, but I'm not too sure if it's still working at this point.Foregoing an actual toggle for enabling and disabling iCloud within your app independent of the system controls, I'd really recommend having some sort of view that can pop into your settings (or somewhere within your UI) whenever there's an unexpected issue with cloud services. While not the same situation, Apple's Setting's app will put a rows at the top of the list when there's immediate action that needs to be taken by the user (like Billing Issues, Updates Pending, see: payment-and-shipping-settings--467x500.jpg). Those dialogs are pretty simple and just work towards helping the user solve the problem.While iCloud should be seamless, problems like this should be available for the user to fix at their own digression after telling them the first time. Otherwise your users will get frustrated with the experience and drop off when they can't find any sort of UI mechanism reflecting that something isn't working to help match their interpretations. Throttling the alert dialogs is a good idea, but each time you show it and the user actively doesn't take action, the less impact it'll have on each reappearance.
Post not yet marked as solved
From a UX perspective, I'd only tell them they hit their quota a single time, give them the option to hop into Settings or disable iCloud syncing within your app, and leave it at that. At most, after explicitly tellng them the first time, I'd just show some sort of icon near the relevant setting (SF symbol exclamationmark.icloud would work well).Then I'd say it's safe to just keep hitting CloudKit with the same request until it succeeds, keeping any additional errors silenced.
To be completely fair, I'm also being paranoid - like I said, I don't think we've seen a bad actor in this fashion ever and like you said, you need to be using a point from within the ecosystem to take advantahe.I hear ya on that last bit, too! 😐 While I know Apple has been able to scale CK in a multitude of ways, it just puts a doubt in the back of my mind about potentially running into a different stopgap like that.
After removing everything from my container from every single device again, taking a break and stepping away from it, then coming back 2 days later, everything seems to be working as expected. 😕
Aw man, I think we'll have to agree to disagree here.Both an app and the OS can be explioted in ways that I don't think you can use a query's request as the trust to selectively access private records from a public pool of others private data. The code shouldn't be guarding the database as there's no way you can confirm that code or the query hasn't been manipulated, and you've got to just trust every device with access to the public database.. which is every device with your app downloaded since you don't even need an iCloud account to access it. And even turning a blind eye to OS and app level expliots, there's the possibility of simple mistakes like mixed up variables or mixed up queries made by a developer that can expose someone elses records; the former examples granting the possibility of of accessing anyones or all records while the latter makes code fragile (and I don't trust myself quite that much, I'm only human). Of course, this is just my opinion; I don't think we've ever seen a CK public database abused in this way by a bad actor, but I doubt there's widespread usage of storing private data like this either. But long story short and in my opinion it's the database's responsiblity to keep records walled off from those who don't have access.(Also just searched that CKShare bug, seems like 5000 limit on records connected to a single share which is totally fine for my usage; how annoying though.)
Whoa - technically anyone can query the public database for any of those records, right? Is that not a security issue when the public database in that way? I most certainly can not place user data in an open area like that, no matter how insensitive I may deem it or what I ask them to agree to. I applaud your ability to work around the constraints though!Man, is that what it has come to to get a properly tested and robust syncing system? Unfortunately just sounds like I hafta sacrifice my account and spend way more time than I should to get things to a place where I'm confident. 😟 Its just frustrating because attempting to do it how Apple intends is rough given the lack of tools. On a side note, CKShare and the shared system as a whole works really great for me, I'd highly recommend dipping into it again if it's been awhile. I haven't really encountered any bugs (knock on wood) it's just building the robust system that handles CloudKit errors, feedback that's the struggle for me now. Having only a single account and one tied to my personal data blows. All I want is a nice solid syncing system!
Well, for example, custom zones aren't supported in the public database (afaik), so that means I can't test and develop sharing between users properly (well, I did through extreme hurdles but I can't test it properly or confidently). I'd also have to change my code pretty dramatically between development and production. Different errors can be thrown from accessing the different databases and there's always human error to account for when handling things manually like that (I'm not sure if you're suggesting I just switch all of my privateDB operations to the publicDB, but that's not really feasible). That's the variability and I just don't think that using the public database is a great solution here because of thati understand not giving developers access to another users private database, but a sandbox user is what this scenario is meant for and was a part of CloudKit dashboard at one point so I don't think it's out of the realm of possibility.
How is this working for you?I added a user as an admin to my team but I can not get them to show up in CloudKit Dashboard's permissions. Did it just take a minute for you? Apparently viewing Sandbox data used to be a possibility in the CloudKit dashboard but it doesn't look like it anymore and the publicDB solution is not a solution IMO as it offers way too much variation from building, to testing, to production.I've nuked my private data so many times at this point and I'd really like to not do that since I actually do enjoy using my app 🙂---Looks like since I have an individual account, I can't add to my team. So, I can not find any other way to access two private user databases, which makes testing and building quite the most horrible process, especially when it comes to sharing. Sounds about right.
Post not yet marked as solved
STILL seeing this as broken in Beta 5 without any sort of answer from Apple.Kind of a big deal for me! Any word at all? Or has anyone by chance found a work around?
