Branching out to Jetpack Compose
summary
Twitter integrates Jetpack Compose across a large legacy app by starting with a single component (button), mapping its design system to Material then copying implementations into foundation to remove unwanted Material concepts like contentColor, and running an Early Access Program of four teams that grows to 13 teams and ~60 modules (≈20–25% of 300 UI modules). Adoption uses an allow list enforced in Gradle builds, a shepherds program for automated code-review oversight, heavy static checks via ktlint rules, Robolectric JVM tests and Paparazzi screenshots; static checks cut review load from ~15 hours/week.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:08Why migrate to Compose
- 3:17Starting with a single component
- 8:15Design system challenges
- 12:51Early access program
- 19:15Developer experience at Twitter
- 27:27Feature parity with Views
- 31:02Onboarding and code reviews
- 33:53Static checks and linting
- 40:18Testing strategies
related talks
43mBranching out to Jetpack Compose
01h 08mAdopting Jetpack Compose @ Scale
01h 09mJetpack Compose for consistency of your apps' UI
26mCompose Beyond Material Design
38mPutting a Jetpack on your legacy codebase
37mAdopting Jetpack Compose Safely
37mSomething old, something new: Adding Jetpack Compose to a large open source Android app
15mBuild beautiful Material Design apps with Jetpack Compose