- I built it because at the time, sync for iOS was a mess: Apple’s original CoreData iCloud sync was very buggy and often failed to sync. An open source alternative seemed nice but poorly maintained, and I wasn’t completely on board with the overall architecture of it. A paid library was great but also quite complex and I had no control over the direction, features, and longevity.
- Apple released their own alternative recently, although it’s only available on newer iOS versions. Additionally, I’m not in control of the CloudKit data schema, and I don’t have the ability to add more complex sync features if needed.
- underlying all of this: the need for control, reliability, and customizability.
So, I spent a few weeks writing my own system. It works well and despite a few hiccups that I’ve resolved, it currently provides reliable, seamless sync for an app with millions of downloads.
- My library is quite generic but I never open sourced it. It would be a nice contribution to the open source community, but I’m not sure I have time to consistently maintain it or review pull requests. I’ve considered it at times, but it’s just never been a priority.
- If sync ever goes wrong, I’m able to debug it and understand exactly what the problem is.
- I can add features any time I like. I plan to do so soon to support a few things that even Apple’s new solution might not encompass.
There are quite a few downsides to it too:
- I need to maintain it myself
- It probably has had less testing than something like Apple’s new solution
- I’ve occasionally shipped a small sync bug, primarily due to lack of ability to test at scale
Overall I think it was worth it, especially given that Apple’s new solution wasn’t available at the time. I learnt a lot; building a generic framework is a great way to grow technically.
If I had to make the same decision again today, I’d heavily consider Apple’s new solution instead, although I’d only choose it if I was confident that it is much more reliable than the prior option they provided.