Let us look at how to set up a basic schema for an offline-first app. First, you define your database schema using WatermelonDB definitions.

import { appSchema, tableSchema } from '@nozbe/watermelondb'

export default appSchema({
  version: 1,
  tables: [
    tableSchema({
      name: 'habits',
      columns: [
        { name: 'title', type: 'string' },
        { name: 'streak', type: 'number' },
        { name: 'is_completed', type: 'boolean' },
        { name: 'created_at', type: 'number' },
      ]
    }),
  ]
})

Next, you define your Models. Models map your database tables to JavaScript classes, making it easy to add custom methods and business logic right next to your data.

import { Model } from '@nozbe/watermelondb'
import { field, text, date, action } from '@nozbe/watermelondb/decorators'

export default class Habit extends Model {
  static table = 'habits'

  @text('title') title
  @field('streak') streak
  @field('is_completed') isCompleted
  @date('created_at') createdAt

  @action async toggleComplete() {
    await this.update(habit => {
      habit.isCompleted = !habit.isCompleted
      if (habit.isCompleted) {
        habit.streak += 1
      }
    })
  }
}

Designing for Privacy by Default

One of the best side effects of building offline-first apps is privacy. When your application stores data locally on the user's device using encrypted SQLite storage, you minimize the need to send sensitive personal data to a remote cloud server.

In apps like Nept Track, users manage personal budgets and daily habits. By keeping this data local by default, the user retains total ownership. There are no analytics trackers reading their personal notes, and no risk of a cloud database leak exposing their private financial logs. If you do need to sync data across multiple devices for a user, you can implement an end-to-end encrypted sync mechanism where the server only sees encrypted blobs it cannot decrypt.

Handling Syncing and Conflict Resolution

Inevitably, offline-first apps need to sync with a backend server when an internet connection becomes available. WatermelonDB provides a built-in sync engine that makes this straightforward.

The sync protocol works on a pull-changes and push-changes strategy:

1. The client asks the server for any changes that happened since the last sync timestamp.
2. The client applies those changes locally.
3. The client sends its own local un-synced changes up to the server.
4. The server accepts the changes or handles conflicts (usually using a "last-write-wins" strategy or custom merge logic).

Keeping your sync logic decoupled from your UI ensures that your app remains usable even when network requests fail or timeout.

Conclusion

Building offline-first apps takes a bit more upfront architectural thought than simply connecting to a REST API, but the payoff is massive. Your users get an app that opens instantly, works everywhere, and respects their privacy.

If you are planning a new mobile app or SaaS product and want to build it right from the ground up, get in touch and let us discuss your project.