Seeking guidance: migrate from SwiftData + CloudKit to SQLiteData for better reliability/control?

[npro1001]

Hey everyone 👋

I’m fairly new to Swift development (I have a broad background, but my current role is in enterprise cloud architecture), and I’ve spent this year diving into building my first iOS apps. It’s been a fun and humbling learning curve, and my current project is now at the TestFlight/App Review stage - which I’m really excited about and expecting to grow.

The app uses SwiftData with CloudKit and includes a share extension. While the local persistence layer has worked great, CloudKit has felt like an unpredictable black box:

• Syncs sometimes stall or fail silently
• Size-related errors at both the record and batch level (even when using CKAssets or external storage) - which has led me to remove or compress data just to stay within CloudKit’s limits
• Migration errors when evolving models or schema
• Lack of visibility into what’s actually syncing or failing

Overall, it’s made it difficult to build confidence in the reliability of CloudKit for production use - especially as a beginner.

I recently came across SQLiteData, and it looks like it could offer the kind of control and visibility I’ve been missing with SwiftData’s CloudKit integration. Plus the ability for iCloud sharing. That said, I don’t want to make a rash decision to swap out my data layer this close to launch.

I’m torn between:

1. Trying to better understand and stabilize CloudKit
2. Migrating to SQLiteData
3. Taking on the overhead (and cost) of a different sync service like Firebase.

I’d really appreciate any perspective or guidance from folks who’ve been in the trenches with CloudKit, SwiftData, and/or SQLiteData - especially around sync reliability, large asset handling, and long-term maintainability.

Thanks so much for taking the time to read this - I’m genuinely trying to make the right architectural decision before launching. 🙏

If you're curious about the app, I've been sharing the journey on instagram

[ljhao24]

Same question, looking for answers.

[mbrandonw]

Hi @ljhao24, please provide more concrete information for your exact use case and questions you have about our library. Also probably better to start your own discussion instead of joining this one since it's likely that your situation is different enough from @npro1001 to warrant its own discussion.

[mbrandonw]

Hi @npro1001, this is a very broad question and so I'm not really sure how to answer it. There are certainly hundreds of developers using the CloudKit sync tools of the library, and so far the only problems we have heard about are things that we were actually able to fix and ship new releases. Contrast that with SwiftData and the best you can do is file a Feedback with Apple and hope it is fixed by next year's WWDC.

As for your bullet points:

• Syncs sometimes stall or fail silently

I'm not entirely sure why that would be happening, but at the very least SQLiteData has extensive logging to let you know what is going on under the hood.

• Size-related errors at both the record and batch level (even when using CKAssets or external storage) - which has led me to remove or compress data just to stay within CloudKit’s limits

Are these errors simply that the iCloud account has run out of space? If so, that is something we are currently working to make observable by users of SQLiteData so that they can message that to their users (#335).

• Migration errors when evolving models or schema

SQLiteData favors explicit migrations over implicit migrations of SwiftData, and typically it greatly reduces these kinds of problems.

• Lack of visibility into what’s actually syncing or failing

As mentioned above, SQLiteData outputs lots of logs that let you know exactly what is happening. This has been helpful for us as library maintainers because it means that people can submit much better bugs for us to investigate. For example, issue #315 was able to provide very precise logs that demonstrated exactly what was happening:

SQLiteData (private.db) nextRecordZoneChangeBatch: scheduled
  ┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  ┃ event      ┃ recordType     ┃ recordName                                          ┃
  ┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
  │ ➡️ Sending │ reminders      │ 48107186-4283-41a7-ad75-23bbf018438b:reminders      │
  │ ➡️ Sending │ remindersLists │ 80ef064a-3dd8-4406-9a7b-548bedd18c65:remindersLists │
  └────────────┴────────────────┴─────────────────────────────────────────────────────┘

SQLiteData (private.db) sentRecordZoneChanges
  ┏━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  ┃ action         ┃ recordType     ┃ recordName                                          ┃ error                    ┃
  ┡━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━┩
  │ 🛑 Save failed │ reminders      │ 48107186-4283-41a7-ad75-23bbf018438b:reminders      │ batchRequestFailed (22)  │
  │ 🛑 Save failed │ remindersLists │ 80ef064a-3dd8-4406-9a7b-548bedd18c65:remindersLists │ serverRecordChanged (14) │
  └────────────────┴────────────────┴─────────────────────────────────────────────────────┴──────────────────────────┘

So overall we feel that there are a lot of benefits of SQLiteData over SwiftData, but at the end of the day it's really up to you to make the call. Do let us know if you have more concrete questions that we can answer though.

[npro1001]

Thanks so much for your response. I wound up moving forward with SwiftData for the time being to avoid having to rewrite my entire data layer.

As per anyone else using CloudKit with SwiftData, I found this package called MyCloudKit that made it easy to implement a custom sync engine. Now I have the visibility I need (visibility that NSPersistantCloudKitContainer does not provide).

Here's that repo and an example using it:
https://github.com/mufasaYC/MYCloudKit
https://github.com/mufasaYC/Bad-Habits