Local-first persistence
Applications read and write through supported local database adapters, so core work remains responsive without a network.
Products Developer tools
Available for trialOffline-first data platform
SyncKit
Make offline a first-class state.
SyncKit is the data layer for applications that must keep working through weak, intermittent, or absent connectivity. Native clients read and write locally; SyncKit records changes, exchanges them with your server, and makes every pending item, retry, and conflict visible.
Guided evaluation · Technical discovery · Trial access through our team
iOS / SwiftAndroid / KotlinFlutterSelf-hosted gateway
Core capabilities
Built around the
work that matters.
Explore how SyncKit works, then talk with us about trial access for your workflow.
Durable change journal
Ordered, identifiable mutations survive restarts and interrupted uploads without hiding what is still pending.
Bidirectional synchronization
Push queued changes, pull server updates from checkpoints, and apply confirmed batches transactionally.
Explicit conflict engine
Choose field merge, client authority, server authority, custom rules, or a human decision for each data type.
How it works
A clear path from
setup to everyday use.
Define the synchronized model
Choose records, relationships, local indexes, permissions, and conflict policies for one bounded workflow.
Run locally by default
Your app commits immediately to the device while the journal tracks what must reach the server.
Exchange and reconcile
Authenticated batches push and pull from checkpoints, with retries and conflicts exposed to the application.
SyncKit architecture
A complete offline data layer.
SyncKit combines local persistence, a durable change journal, server checkpoints, conflict policies, and operational visibility. Teams can begin with one workflow and extend the model as the evaluation proves its behavior.
Local store adapter
Keep reads and writes responsive through a supported device database while SyncKit tracks synchronization metadata separately.
Durable change journal
Record ordered mutations with stable identifiers so interrupted uploads can resume without silently repeating business effects.
Cursor-based pull
Fetch server changes from a checkpoint, apply them transactionally, and advance the cursor only after a successful local commit.
Sync gateway
Authenticate each device, enforce tenant and record scope, validate schemas, and return explicit acknowledgements or conflicts.
Conflict engine
Evaluate per-collection policies while preserving both versions whenever business meaning requires application or human review.
Conflict policies
Business meaning stays in control.
Field merge
Combine non-overlapping edits while preserving which side changed each field.
Server authority
Protect server-controlled states such as approval, billing, or assignment.
Client authority
Preserve designated device-owned values such as drafts or locally captured evidence.
Human review
Return both versions when the correct outcome depends on business meaning.
Operational visibility
Know what every record is doing.
- Per-record pending and failed state
- Queue depth and oldest pending change
- Last successful push and pull checkpoints
- Retry reason with correlation identifiers
- Safe reset and resync tools
- DebugStream diagnostic integration
Safe adoption path
Start narrow. Expand with evidence.
- Choose one collection and one user group
- Import existing server records into the local store
- Run downloads before enabling offline edits
- Enable queued writes with conservative conflict rules
- Review sync health and expand deliberately
Architecture
How SyncKit
fits together.
A clear division between the product interface, processing layer, and the systems your team already owns.
01Client data layer
Supported database adapters, local indexes, migrations, and reactive reads.
02Change protocol
Stable operation IDs, ordered mutations, attachment references, and checkpointed pulls.
03Sync gateway
Tenant authorization, schema validation, deduplication, batch acknowledgements, and conflict results.
Technical profile
Built for integration,
not a closed box.
Trial onboarding confirms the exact environment, product boundary, and success criteria for your implementation.
Platforms & surfaces
iOS / SwiftAndroid / KotlinFlutterSelf-hosted gateway
Connects with
SQLite adaptersPostgreSQL backendObject storageDebugStream diagnostics
ConsistencyEventual, per-record observable state
TransportAuthenticated batched HTTPS
Change identityClient operation ID + server version
AttachmentsResumable references with checksum
ConflictsField, client, server, custom, human review
Security & control
Deliberate boundaries
from the beginning.
- Every pull and push enforces tenant and record authorization
- Devices never receive direct database credentials
- Schema versions and migration compatibility are checked
- Local encryption uses platform storage and application key policy
Who it's for
Made for real workflows.
Field and inspection apps
For jobs, forms, photos, signatures, and evidence captured at unreliable locations.
Sales and service platforms
For mobile CRM, routes, accounts, and tasks that must stay useful between connections.
Logistics and inventory teams
For operational records updated across warehouses, vehicles, and customer sites.
Guided product trial
Evaluate SyncKit
against real work.
We scope the trial around one meaningful workflow, the environments you use, and evidence your team can assess.
- 01
Select one collection and representative offline users
- 02
Model permissions, mutations, deletion, and conflict rules
- 03
Run interrupted sync and competing-edit exercises
- 04
Review observability, recovery, and expansion readiness
What the evaluation includes
Discuss trial access ↗Product access for the agreed scope, technical onboarding, implementation guidance, and a review of the findings.
A few answers
Explore with confidence.
A closer look at the scope and trial experience for SyncKit.
How can I try SyncKit?
SyncKit is available through a guided trial. Tell us about your requirements, platform, and evaluation goals; our team will discuss fit, access, and the right trial scope with you.
Can SyncKit synchronize any database automatically?
SyncKit connects through supported local adapters and a defined server schema. It is not transparent database replication: your integration explicitly selects records, permissions, operations, and conflict behavior.
Could conflicts always be resolved without user input?
No. Some conflicts depend on business meaning. SyncKit is designed to expose the competing changes so the application can apply an agreed rule or request a decision.
Explore SyncKit
Bring us your
real workflow.
Share your platform, requirements, and evaluation goals. We'll discuss the product and arrange a focused trial where it fits.