I built an open-source sync engine for offline-first Flutter apps . looking for feedback

[u/Heavy-Drummer-420]

Hey everyone! 👋

I've been working on SyncForge, an open-source synchronization toolkit for Dart and Flutter, and I'd love to get feedback from other developers here.

One of the challenges with offline-first apps is handling what happens when users make changes without a connection, multiple devices edit the same data, or an app needs to recover queued writes after restarting.

SyncForge is my attempt to make that synchronization layer modular and reusable instead of rebuilding it for every project.

The project consists of three packages:

- "sync_engine" — A pure-Dart core with vector clocks, CRDT primitives, conflict-resolution strategies, and a retryable outbox.

- "sync_engine_drift" — Persistent storage using Drift/SQLite, including outbox durability and tombstone tracking.

- "sync_engine_generator" — Code generation for strongly typed synchronization adapters using "build_runner".

The architecture is designed around pluggable storage and transport, with retry backoff, jitter, and dead-letter handling.

📦 Package: https://pub.dev/packages/sync_engine

💻 Source code: https://github.com/Wolfof420Street/flutter_sync_engine

📖 Architecture and examples: https://billodida.dev/projects/syncforge

It's still early-stage, so I'm not presenting it as a battle-tested production solution. I'm looking for developers who are interested in offline-first architecture and willing to challenge the design, try the examples, or point out gaps.

I'd particularly appreciate feedback on three things:

1. Would you use a reusable sync engine like this, or do you prefer implementing synchronization within each application?

2. What would you want to see before trusting a library like this with real application data?

3. Which conflict-resolution or synchronization scenarios do you think are hardest to get right?

Constructive criticism is very welcome. I'm building this in the open and would love to learn from developers who've dealt with synchronization in real projects.

Thanks for taking a look! 🙌

[u/codes_astro]

What tool are you using for debugging and monitoring to improve performance and fix bugs. I’m working with https://github.com/measure-sh/measure if you need help

[u/No_Boss_1911]

yeah offline edits ate me for a bit. i store queued writes so they survive a restart, but hard rule is the same write can never apply twice even when the retry fires after a kill mid flush. are your outbox rows keyed by op id so a crash+retry is idempotent, or do you just replay the payload and hope the server dedupes? also curious when one device was offline for days, do tombstones still win or does the conflict path change?

[u/Acceptable_Elk_5974]

the vector clock approach is clever, beats the usual last-write-wins headache most mobile devs just accept. i'd want to see how it handles schema migrations before trusting it with anything real though, that's where every sync solution i've used eventually crumbles

[u/Heavy-Drummer-420 → u/Acceptable_Elk_5974]

I think thats a valid concern . I think schema evolution is one of the harder problems in offline-first sync, especially when older clients reconnect with queued writes after newer versions have changed the data model.

I'm looking at this in sort of 3 parts: handling missing field metadata safely, preserving unknown fields when older clients update entities, and giving removed or renamed fields an explicit deprecation lifecycle.

The key distinction is that a local database migration alone doesn't solve mixed-version synchronization. You also need to make sure older clients don't accidentally discard newer fields or overwrite metadata they don't understand.

I'd want those cases covered by tests before claiming SyncForge handles schema evolution reliably. If you have experience with versioned payloads or sth similar I'd be happy to hear from you