While I understand the use case where a user is signing in for the first time and we request the user's information the scopes, it's returned fine. However, like others who have run into the issue of losing the user's information, what is the practice for retrieving it again? There doesn't seem to be a way to recover user's information after their first authentication, other than provisioning a new device or some other hack. Please advise.

I'm also running into issues with CLLocation and the distance predicate. I get this: Cloud Query Error - Fetch Locations: &lt;CKError 0x60000153a490: "Invalid Arguments" (12/1009); "Field 'location' has a value type of BYTES and cannot be queried using filter type NEAR"&gt;   static func fetchNearbyLocations(_ location: CLLocation, radiusInMeters: CLLocationDistance, onComplete: @escaping (_ records:[CKRecord]?) -> Void) {         // convert radius in meters to kilometers         let radiusInKilometers = radiusInMeters / 1000.0         //set up predicate for query         let locationPredicate = NSPredicate(format: "distanceToLocation:fromLocation:(location, %@) < %@", location, NSNumber(value: radiusInKilometers))         //set up query based on predicate         let query = CKQuery(recordType: "Location", predicate: locationPredicate)         //Execute query         CKContainer(identifier: CloudKitHelper.containerId).publicCloudDatabase.perform(query, inZoneWith: nil) { (records, error) in             if let error = error {                 DispatchQueue.main.async {                     print("Cloud Query Error - Fetch Locations: \(error)")                 }             } else {                 onComplete(records)             }         }     } The location attribute in the entity is type Transformable with Custom Class CLLocation. What am I missing here? Thanks in advance.

Same problem here. I've read that a ticket has been filed, and the workaround is to set a state variable. This seems wonky and potentially working around some reasoning that apple has for calling it more than once, which they don't indicate why.

I hate to speculate, but this was working with iOS 14, just before WWDC2020. Then they announced a security vulnerability that was discovered with sign-in with Apple and the keychain, and immediately following that announcement, the simulator Sign-In with Apple would just hang with an infinite spinner. Others have reported that the TFA is the culprit, so perhaps there is something to that and the backdoor that they discovered. Let's hope they figure out a way to patch it up. Edit: Please upvote this...

Same issue here, iOS 14.5 Beta 7, SwiftUI app.

I'm also facing this issue; although, I am using CoreData.

I'm not using firebase. I'm using a custom DataTransformer. Specifying the type here fixed it:     override static var allowedTopLevelClasses: [AnyClass] {         return [NSArray.self, NSString.self]     }

Thank you for providing a workaround for now. This at least cleans up the warnings.

Tried signing out of iCloud and signing back in, syncing, but it still fails. This is something else.

More info added to the issue. I added a do catch around modify subscription method, and see the error returned by CloudKit: "User rejected a prompt to enter their iCloud account password" Obviously, I'm not seeing any prompts. Error is: `do {             _ = try await database.modifySubscriptions(saving: [subscription], deleting:nil             self.setSubscriptionState(recordType: recordType)         } catch(let error) {             logger.debug("(error.localizedDescription)")         } `

Huge improvement in iOS 15 Beta. Thank you, @Apple.

I remember reading something in one of Apple's recent release notes about adding support for AppStorage in ObservableObjects. I don't recall the exact build, but if someone has time to dig through release notes, it would be nice to have the reference. In other words, it should work in the latest SwiftUI release.

Are you by any chance setting breakpoints inside of code that's in a framework? I just read somewhere that this is a known issue.

Disregard, that's minimum target.

did you ever come up with a solution for this? I’m not as concerned about the size, and I’m not sure which system fields would be so large, but I do need to know the best solution as it does make sense performance wise. thank You!