You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Trying to better understand and stabilize CloudKit
Migrating to SQLiteData
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
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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:
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
Beta Was this translation helpful? Give feedback.
All reactions