Skip to content
In development. Nothing in Store 6 is published yet.

Migrating from Store 4

Where you are starting from

Store 4 used com.dropbox packages. That history remains visible in Store 5's own StoreReadRequest KDoc, which references com.dropbox.android.external.store4.impl.SourceOfTruth.

Two release facts keep this path bounded:

  • Store 5's early multiplatform release says concepts and usage were unchanged from Store 4.
  • The Store 5 stable release describes its additions over Store 4 as having no breaking changes.

That means the Store 5 to Store 6 component map applies to a Store 4 codebase. You skip the Store 5-only rows instead of first migrating the application to Store 5.

Rows of the Store 5 map that do not apply to you

Store 5 added MutableStore, Validator, fallback mechanisms, write-conflict resolution, and NoNewData after Store 4. A Store 4 application has none of those additions to translate.

For a Store 4 holdout, per-call freshness policies and the journalled mutation path are new capabilities to evaluate, not existing behaviors that must be ported. Use the component map for the rows that remain: Store, Fetcher, SourceOfTruth, and Converter.

The mapping that does apply

Store 4-era responsibilityStore 6 pathDetail
Fetcherfetcher { }, fetcherOfResult { }, or the experimental seam FetcherA fetcher is the one required Store 6 builder input. See Fetchers.
Persister / SourceOfTruthThe two-parameter persistence seam or a Room/SQLDelight adapterSee Persistence, Room, and SQLDelight.
ConverterNo direct Store 6 analog. Conversion lives in the fetcher and persistence adapter callbacks.See the component map.
Read sitesget(key, freshness) for a point read, or stream(key, freshness) for an ongoing result flowThe request and response tables are in Migrating from Store 5.

Store 5's KDoc preserves two Store 4-era read spellings: store.fresh(key) and store.cached(key, refresh = true). In Store 6:

  • store.fresh(key) maps to get(key, Freshness.MustBeFresh) when the caller needs one fresh value.
  • store.cached(key, refresh = true) maps to an ongoing stream(key) plus deliberate invalidate(key) when the caller requests a refresh. It is not a one-call mechanical rename.

The Store 6 builder side starts with the compiled quickstart shape:

kotlin
val users = store<UserKey, User> {
    fetcher { key -> FakeApi.getUser(key.id) }
}

Inside the quickstart's stream collector, the result is handled exhaustively:

kotlin
when (result) {
    is StoreResult.Loading -> println("Loading…")
    is StoreResult.Data -> println("Data(name=${result.value.name}, origin=${result.origin})")
    is StoreResult.Revalidated -> println("Revalidated(age=${result.age})")
    is StoreResult.Error -> println("Error(${result.error})")
}

A compilable Store 4 example remains pending until the worked migration is available. The two Store 4-era spellings above come from the retained Store KDoc. Both Store 6 fences come from the repository's executable quickstart.

Coordinates and coexistence

Store 6 artifacts use the existing group org.mobilenativefoundation.store and packages under org.mobilenativefoundation.store6.*. Nothing is published until 6.0.0-alpha01.

Store 4 has no equivalent coexistence guarantee. If the existing Store 4 dependency still resolves in your build, keep it in place while adding the needed store6-* artifacts and moving one complete screen at a time.

The formal 6.x coexistence and interop promise begins with Store 5: store5.* and store6.* coordinates live side by side for the whole 6.x major, and store6-store5-interop is supported for all of 6.x. No Store 4 artifact availability or Store 4 interop artifact is guaranteed. Plan each Store 4 to Store 6 move as a complete screen boundary.

What this page will grow into

Before GA, this page still needs three concrete artifacts:

  1. A worked port of a small Store 4 setup covering its fetcher, persister, and read sites, sized to the roadmap's “in an afternoon” promise.
  2. A symbol-level rename table verified against a real Store 4 project.
  3. A migration checklist that can be completed without consulting release history.

Documentation is part of the GA gate. Until these items are complete, this page remains a thin migration path.

Continue with Migrating from Store 5, the component map, and the Store 6 quickstart.


Source recorded 2026-08-12 ·main@c67a94ed· pre-6.0.0-alpha01