Mobius-Loopy UI Architecture
summary
Spotify builds a lightweight unidirectional framework called Mobius that replaces ad‑hoc presenters with a strict update function that takes immutable model + event and returns a new model plus effects, handled by separate effect handlers (examples use RXJava/Kotlin in a Mobius RX module). It enforces sequential, atomic event processing, ships with a small test library for deterministic update specs, and runs in production (six months live across a repo with 100+ Android committers and 400+ modules). Teams report much better logs, debugging and a surprising moflow modeling practice.
AI-written summary · about
chapters (16)
- 0:00Welcome and introduction
- 1:12Why Mobius at Spotify
- 3:42Mobius design goals
- 5:07Inspiration and prior art
- 8:36Finite state machines in UI
- 10:19Model and events explained
- 12:03Update function walkthrough
- 15:41Introducing effects
- 18:52Effect handlers
- 21:19Handling effects with Rx
- 24:06External events and full loop
- 25:32Testing and utilities
- 27:17Mobius vs MVI comparison
- 31:34Production experience with Mobius
- 34:48Moflow and modeling flow
- 36:22Q&A session
