Skip to content

title: Cross-platform preference parity type: concept created: 2026-04-24 updated: 2026-04-24 tags: [cross-platform, mobile, desktop, ios, android, preferences, state-consistency, unified-model, client-sync] sources: [2026-03-19-slack-how-slack-rebuilt-notifications] related: patterns/unified-preference-model-for-cross-client-state, concepts/explicit-state-over-implicit-sync, concepts/mental-model-preference-coherence, concepts/cross-platform-client-library, systems/slack-notifications-2-0

Cross-platform preference parity

Cross-platform preference parity is the discipline of maintaining a single shared preference model across all client platforms (desktop, iOS, Android, web) — with explicit named override points where platforms legitimately diverge — rather than letting each client evolve its own preference schema with drift-prone sync logic stitching them together.

The anti-pattern is per-platform preference drift: each client owns its own preference UI + storage format + local defaults, and a cross-client sync layer tries to reconcile them after the fact. This is the legacy Slack state described in the 2026-03-19 How Slack Rebuilt Notifications post: "Desktop and mobile each had their own preference systems, with different options and behaviors. A 'nothing' setting on mobile meant something entirely different from 'Off' on desktop. Users couldn't predict what would happen when they changed a setting."

The parity discipline

Three load-bearing properties:

  1. Shared schema: the preference storage model is defined once and applies across all clients. No per-platform values with the same semantic meaning; no per-platform enums that overlap ambiguously.
  2. Explicit override points: where platforms legitimately diverge (e.g. mobile-specific badge controls on Slack Android), the divergence is a named dimension in the shared schema — not an implicit per-platform value.
  3. Mobile matches desktop by default: when a preference change is made on one platform, the expectation is that other platforms inherit it; overrides are explicit opt-ins, not implicit defaults.

Slack's instance

Canonical verbatim from the post: "The goal was simple: mobile should match desktop by default, with the option to override when needed."

The new preference hierarchy is one model:

  • What to notify you about — shared: All new messages / Mentions and DMs (default) / Mute
  • Push notifications — shared with per-platform granularity: desktop and mobile (default) / desktop only / mobile only / disabled
  • Advanced — explicit override dimension for mobile-specific customisation (badge-all-unreads, etc.)

The shared part of the hierarchy is canonical; the explicit-override part acknowledges that mobile has legitimately different interaction surfaces (home-screen badges) without implying per-platform drift in the shared axes.

Implementation discipline

  • Single source of truth for schema — one spec, one wire format, one storage backend.
  • Reusable UI components across clients — Slack rewrote its iOS preference UI using "reusable React components" to structurally match desktop. Same copy, same layout, same hierarchy.
  • Rewrite legacy client screens when the cost is justified — Slack rewrote "some of the oldest pages in Slack's iOS app — built before our modern architecture" specifically for this project. The alternative — patching legacy UI to simulate parity — is viable short-term but accrues technical debt against every future preference change.
  • Explicit state, not implicit sync — paired with concepts/explicit-state-over-implicit-sync: store desktop and mobile as two independent values, not one value + a sync derivation rule.

Why parity is hard

Client platforms have genuinely different:

  • Interaction primitives (touch vs pointer, notification-center conventions, app-backgrounding semantics).
  • Default behaviours (iOS notification categories vs Android channels vs desktop OS-level integration).
  • Performance envelopes (mobile network constraints, background-wake policies).

Parity doesn't mean "pretend the platforms are identical" — it means the user's mental model of "what is my preference?" is one model, and genuine platform-specific behaviours are explicit dimensions in that model rather than implicit drift between models.

Support-burden dimension

Slack's framing positions cross-platform parity as a support-burden reduction as much as a UX improvement: users "configure notifications on desktop only to find mobile behaving completely differently, leading to confusion and duplicate configuration work" — i.e. drifting client preference schemas multiply the CX ticket volume because every configuration action on one client triggers a new set of "why doesn't my other client match?" tickets. See concepts/support-burden-as-architecture-signal.

Seen in

  • systems/slack-notifications-2-0 — canonical instance. Single shared schema (desktop, desktop_push_enabled, mobile) across iOS, Android, desktop with explicit mobile-Advanced override dimension.
Last updated · 470 distilled / 1,213 read