Post

Replies

Boosts

Views

Activity

Reply to Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context
Thanks, Quinn. I think I normally wouldn't have worried too much about this, but since I'm in the midst of the Swift 6 concurrency migration, I was worried it was related to something in my code. I think the message should state more clearly that it's an internal speech synthesizer issue, not really a "structural Swift Concurrency issue". I filed FB20484368. Thanks again for your help!
Oct ’25
Reply to Using a local model for Xcode Assist
Answering my own question: I was able to do this by downloading LM Studio and installing a Devstral model from Mistral. Just start the server for that model and then set up a local model in Xcode. It's a local model, and works even with wifi turned off. I found the model didn't work nearly as well at understanding even medium-sized codebases and making changes. It was better suited for writing small snippets of code or maybe analyzing a single file.
Dec ’25
Reply to Getting a list of deleted CloudKit records with an expired change token
Hi Ziqiao, thanks for the reply. Let me explain the situation I'm facing with my CloudKit-powered app. Device A and B are both fully synced with the cloud. On Device A, the user deletes a bunch of records and continues to use the app, letting the app sync in the background. The user waits a few weeks before opening the app on Device B. When they open the app, it attempts to sync. The change token is expired, so it retrieves all of the records on the server. My app is designed to treat this as if this is the user's first sync (a "unify" sync), so it compares all records on the server with all local records, then uploads any local records missing from the cloud and downloads any cloud records missing from the local database. At this point, all of the items deleted in step 2 have been re-downloaded onto Device B. Currently, my app never checks deletedRecordIDs on a unify sync. An easy fix would be to start processing this array even on unify syncs. But from your reply, it sounds like this will be an empty array on Device B because the deletions happened on Device A. Is that true? If so, how can I resolve this problem? Unfortunately, it's somewhat common for my users to have a second device that they use very infrequently, and they get annoyed when previously deleted records re-appear on their second device. To make my question more concrete, here's some CloudKit code demonstrating the scenario: // device A let newRecord = CKRecord(recordType: "Entry", recordID: CKRecord.ID(recordName: "test")) newRecord["name"] = "Length" try await self.database.save(newRecord) // device B let (_, _, savedChangeToken, _) = try await self.database.recordZoneChanges(inZoneWith: self.zoneID, since: nil) // successfully receives the Entry record with id "test" and saves locally // we also persist savedChangeToken somewhere on device B // device A try await self.database.deleteRecord(withID: CKRecord.ID(recordName: "test")) // several weeks pass // device B (uses savedChangeToken from above, which has now expired) let (_, deletions, _, _) = try await self.database.recordZoneChanges(inZoneWith: self.zoneID, since: savedChangeToken) // is the following true or false? deletions.map(\.recordID).contains(CKRecord.ID(recordName: "test")) If it's false, how do I resolve the problem described above (deleted records re-appearing on the rarely-used device)?
Jan ’26
Reply to Getting a list of deleted CloudKit records with an expired change token
Hi Ziqiao, The important detail is step 3 - the user hasn't even opened Device B in weeks so that device is totally out of the loop. It's unaware of any deletions (or any changes at all) that have happened since step 1. Everything was synchronized initially, but then the user starts deleting items on Device A, which get synced up to iCloud. Meanwhile, back on device B, the app has been left unopened for weeks. When the user opens it up, they'll get .changeTokenExpired, and I'll fall back to the "unify" logic, the same behavior we use the first time this device syncs. I'm really confused about how deleted record ID's work. For my use case, it doesn't matter which device the record was created on - any device that has had a long delay between fetches such that it needs to do a full fetch will need a list of everything that was deleted on the server since the last fetch. For example, a user initially creates a record on Device A, syncs it to iCloud, Device B fetches. Later on, the user removes it on Device A and so my application code on Device A also removes the record from iCloud. Device B, weeks later, fetches for the first time. It needs to know that the record has been deleted since its last fetch, regardless of the fact that, sometime far in the distant past, Device A had originally created it. Does that make sense?
Feb ’26
Reply to Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context
Thanks, Quinn. I think I normally wouldn't have worried too much about this, but since I'm in the midst of the Swift 6 concurrency migration, I was worried it was related to something in my code. I think the message should state more clearly that it's an internal speech synthesizer issue, not really a "structural Swift Concurrency issue". I filed FB20484368. Thanks again for your help!
Replies
Boosts
Views
Activity
Oct ’25
Reply to Using a local model for Xcode Assist
Answering my own question: I was able to do this by downloading LM Studio and installing a Devstral model from Mistral. Just start the server for that model and then set up a local model in Xcode. It's a local model, and works even with wifi turned off. I found the model didn't work nearly as well at understanding even medium-sized codebases and making changes. It was better suited for writing small snippets of code or maybe analyzing a single file.
Replies
Boosts
Views
Activity
Dec ’25
Reply to Getting a list of deleted CloudKit records with an expired change token
Thanks, that's great to know! Just to understand it better: it will usually return all deleted records since the last change token, but if I pass nil, then which deleted records will I get: all deleted records ever? all deleted records since device last received data? something else? Just want to anticipate how many record ID's I should expect.
Replies
Boosts
Views
Activity
Jan ’26
Reply to Getting a list of deleted CloudKit records with an expired change token
Hi Ziqiao, thanks for the reply. Let me explain the situation I'm facing with my CloudKit-powered app. Device A and B are both fully synced with the cloud. On Device A, the user deletes a bunch of records and continues to use the app, letting the app sync in the background. The user waits a few weeks before opening the app on Device B. When they open the app, it attempts to sync. The change token is expired, so it retrieves all of the records on the server. My app is designed to treat this as if this is the user's first sync (a "unify" sync), so it compares all records on the server with all local records, then uploads any local records missing from the cloud and downloads any cloud records missing from the local database. At this point, all of the items deleted in step 2 have been re-downloaded onto Device B. Currently, my app never checks deletedRecordIDs on a unify sync. An easy fix would be to start processing this array even on unify syncs. But from your reply, it sounds like this will be an empty array on Device B because the deletions happened on Device A. Is that true? If so, how can I resolve this problem? Unfortunately, it's somewhat common for my users to have a second device that they use very infrequently, and they get annoyed when previously deleted records re-appear on their second device. To make my question more concrete, here's some CloudKit code demonstrating the scenario: // device A let newRecord = CKRecord(recordType: "Entry", recordID: CKRecord.ID(recordName: "test")) newRecord["name"] = "Length" try await self.database.save(newRecord) // device B let (_, _, savedChangeToken, _) = try await self.database.recordZoneChanges(inZoneWith: self.zoneID, since: nil) // successfully receives the Entry record with id "test" and saves locally // we also persist savedChangeToken somewhere on device B // device A try await self.database.deleteRecord(withID: CKRecord.ID(recordName: "test")) // several weeks pass // device B (uses savedChangeToken from above, which has now expired) let (_, deletions, _, _) = try await self.database.recordZoneChanges(inZoneWith: self.zoneID, since: savedChangeToken) // is the following true or false? deletions.map(\.recordID).contains(CKRecord.ID(recordName: "test")) If it's false, how do I resolve the problem described above (deleted records re-appearing on the rarely-used device)?
Replies
Boosts
Views
Activity
Jan ’26
Reply to Getting a list of deleted CloudKit records with an expired change token
Hi Ziqiao, The important detail is step 3 - the user hasn't even opened Device B in weeks so that device is totally out of the loop. It's unaware of any deletions (or any changes at all) that have happened since step 1. Everything was synchronized initially, but then the user starts deleting items on Device A, which get synced up to iCloud. Meanwhile, back on device B, the app has been left unopened for weeks. When the user opens it up, they'll get .changeTokenExpired, and I'll fall back to the "unify" logic, the same behavior we use the first time this device syncs. I'm really confused about how deleted record ID's work. For my use case, it doesn't matter which device the record was created on - any device that has had a long delay between fetches such that it needs to do a full fetch will need a list of everything that was deleted on the server since the last fetch. For example, a user initially creates a record on Device A, syncs it to iCloud, Device B fetches. Later on, the user removes it on Device A and so my application code on Device A also removes the record from iCloud. Device B, weeks later, fetches for the first time. It needs to know that the record has been deleted since its last fetch, regardless of the fact that, sometime far in the distant past, Device A had originally created it. Does that make sense?
Replies
Boosts
Views
Activity
Feb ’26