Skip to content

CONCEPT Cited by 1 source

Shared mobile foundations

Shared mobile foundations are the cross-cutting libraries and platform services (identity, real-time monitoring, performance measurement, networking, error reporting, build tooling, feature-flag SDK, analytics SDK, etc.) that multiple mobile apps in a consumer-app portfolio consume as a single implementation rather than each re-implementing.

The architectural fact: shared foundations require per-app maturity first, and work against teams trying to establish maturity in parallel with building the platform.

The canonical timeline

Shopify's five-year React Native migration is the canonical disclosure (see Mustafa Ali):

  1. Years 1–3 (2020–2023): per-app autonomy. Each team "built things their own way". Shared native foundations built over years of prior iOS/Android development did not carry over to RN. A conscious trade-off: "we optimized for speed over consistency."
  2. Year 3 inflection (end of 2023): maturity reached. All apps reached sufficient RN maturity that shared- foundations extraction became worthwhile.
  3. Year 4+ (2024→): extraction. "We have since started extracting common components like Identity, real-time monitoring, performance measurement, etc into shared libraries that all apps consume."

The architectural insight the timeline captures:

"It wasn't worth investing in creating those shared foundations at the time either because we were still learning how to build apps in RN. We were beginners again and had to first put in the time and effort to develop expertise."

Why speed-over-consistency is often right

Attempting to build shared foundations before the apps themselves exist means building for an audience you don't yet understand. The shared-library team designs APIs against hypothetical needs; feature teams build around mismatches; the library gets redesigned repeatedly. By letting each app build its own first, the organisation learns what the actual common requirements are — which can then be factored once, correctly, informed by multiple real production instances.

The cost of the approach: duplicated work during the autonomy phase. Shopify describes this candidly: "teams to solve the same problems multiple times, reinventing the wheel." This is a short-term cost; the long-term cost of premature abstraction is higher.

Extraction criteria

Shopify's three worked examples:

  • Identity — user authentication flow; cross-cutting requirement shared by every app; privacy / security specialism makes shared-implementation valuable.
  • Real-time monitoring — crash reporting, performance monitoring; every app needs the same telemetry shape for comparable dashboards + alerts.
  • Performance measurement — client-side perf instrumentation; want every app's perf numbers to be measured the same way to be comparable.

The pattern: infrastructure, not features. Shared foundations are the cross-cutting concerns that look the same across apps, not the business-logic features that differentiate them.

Benefits of shared foundations

Per Ali: "This allows teams to avoid solving problems that have already been solved in other parts of the company. It also spreads knowledge and expertise, and every app automatically benefits from improvements that are made to these shared components. ... gives us tremendous leverage and frees up engineering bandwidth that can be applied to shipping more value to our users."

Four distinct wins:

  1. De-duplication — one implementation, not N.
  2. Knowledge spread — the shared library becomes a forcing function for engineering best-practice across the org.
  3. Automatic improvement propagation — fix once, benefit everywhere.
  4. Bandwidth reallocation — engineers freed from re- implementing the foundation can ship features.

Failure modes to watch for

  • Premature extraction — building the shared library before enough apps exist to inform it (Shopify's pre-2023 decision to not do this).
  • API-design paralysis — over-general shared library that tries to serve every possible future consumer. Mitigated by extracting from two or three concrete working instances rather than from pure imagination.
  • Version-skew friction — shared library upgrades that must be rolled out across N apps, each on different framework versions and release schedules. Related to framework- upgrade team rotation — you need the version-skew discipline first.
  • Over-shared foundations — extracting things that don't actually need to be shared, just because they look similar. Not every common-looking component is the same component.

Seen in

Last updated · 470 distilled / 1,213 read