Inspiration

Modern mobile apps are expected to work everywhere — even with unreliable networks, offline usage, and multiple devices editing the same data simultaneously.

Building offline synchronization correctly requires solving distributed systems problems: conflict resolution, causal ordering, data merging, retries, persistence, and migrations.

Most Flutter developers should not need to become distributed systems engineers just to make their apps work offline.

We wanted to create a developer tool that hides this complexity behind a simple Flutter-native experience while still providing production-grade guarantees.

The inspiration for SyncForge was to bring CRDT-based synchronization, code generation, and offline-first architecture to Flutter developers in a way that feels as simple as adding annotations to a model.

What it does

SyncForge is an offline-first synchronization engine for Flutter applications.

Developers annotate their models with @Syncable, and SyncForge generates the adapters, serializers, and CRDT merge logic needed for synchronization.

The library provides:

  • Pure Dart CRDT primitives:

    • Vector clocks
    • Grow-only counters
    • Grow-only sets
    • Field-level Last Write Wins resolution
  • Offline-first SyncEngine:

    • Optimistic updates
    • Local persistence
    • Retry queues
    • Dead-letter handling
    • Rollback after rejected writes
  • Conflict resolution:

    • Concurrent edits are merged at the field level
    • Independent changes are preserved
    • Conflict events are exposed to applications
  • Storage abstraction:

    • Pluggable persistence layer
    • Drift database support
  • Developer experience:

    • Annotation-based models
    • Generated adapters
    • Generated serializers
    • Type-safe adapter registration

The result is that Flutter developers can add reliable offline synchronization without manually implementing distributed systems logic.

How we built it

SyncForge was built using Codex with GPT-5.6 as a development partner.

The project was designed and implemented as a multi-package Dart/Flutter monorepo:

  • sync_engine

    • Pure Dart CRDT core
    • Vector clocks
    • Merge algorithms
    • Sync protocol
  • sync_engine_generator

    • build_runner code generation
    • Generated adapters
    • Generated serializers
    • CRDT merge logic
  • sync_engine_drift

    • Offline persistence
    • Tombstones
    • Metadata storage
    • Migration support
  • Example applications

    • Offline task manager
    • External consumer notes application
    • Conflict Playground
    • Minimal App

Codex accelerated development by helping generate:

  • CRDT implementation scaffolding
  • test infrastructure
  • generated adapter patterns
  • documentation
  • CI workflows

However, correctness decisions were driven through engineering validation:

  • property-based CRDT tests
  • randomized merge testing
  • replica convergence tests
  • migration fixture testing
  • external consumer testing

A major design challenge solved during development was replacing entity-level LWW conflict resolution with field-level metadata so independent concurrent edits would not overwrite each other.

Challenges we ran into

The biggest challenge was correctness.

Offline synchronization is deceptively difficult because a system can appear to work while silently losing user data.

One major issue discovered during testing was that entity-level Last Write Wins resolution caused unrelated fields edited on different devices to overwrite each other.

We redesigned the system around field-level LWW metadata:

  • Each synchronized field maintains its own timestamp and node identity.
  • Entity vector clocks continue handling causal ordering.
  • Tombstones maintain delete precedence.

We also faced challenges around:

  • designing a type-safe generated adapter system,
  • maintaining a pure Dart CRDT core,
  • ensuring generated code worked for external consumers,
  • testing migration compatibility.

Codex was especially useful for exploring implementations quickly, but automated generation was always validated through tests and architectural review.

Accomplishments that we're proud of

We are proud that SyncForge is not just a demo — it is a working foundation for production-style offline synchronization.

Key accomplishments:

✓ Built a pure Dart CRDT engine with randomized merge-law verification.

✓ Implemented field-level conflict resolution that preserves independent concurrent edits.

✓ Created annotation-driven code generation similar to developer tools Flutter developers already use.

✓ Built optimistic offline workflows with rollback and conflict visibility.

✓ Created a Drift persistence adapter with tombstones, acknowledgements, and pruning.

✓ Built external consumer examples proving developers can integrate the package without accessing internal APIs.

✓ Used Codex and GPT-5.6 throughout the development process while maintaining correctness through automated testing.

The project demonstrates that AI-assisted development can accelerate complex engineering while still requiring careful architecture and verification.

What we learned

We learned that AI-assisted development works best when paired with strong engineering constraints.

Codex dramatically accelerated implementation speed, especially for:

  • repetitive code generation,
  • test scaffolding,
  • documentation,
  • refactoring exploration.

However, distributed systems require human-led architectural decisions.

The most important lesson was that correctness comes from:

  • explicit models,
  • strong invariants,
  • property testing,
  • adversarial scenarios,
  • and careful API design.

The combination of GPT-5.6, Codex, and engineering discipline allowed us to explore a problem area that normally requires a much larger development team.

What's next for SyncForge

Future improvements include:

  • More backend adapters:

    • Supabase
    • Firebase
    • GraphQL
    • Custom REST APIs
  • Background synchronization through Flutter federated plugins:

    • Android WorkManager
    • iOS BGTaskScheduler
  • More CRDT strategies:

    • counters
    • collaborative text
    • custom merge policies
  • Production hardening:

    • benchmarks
    • performance profiling
    • security guidance
    • package publishing

The long-term vision is to make reliable offline-first architecture accessible to every Flutter developer.

Built With

Share this project:

Updates