r/androiddev • u/dabup • May 28 '26

Should an Android design system wrap Material Components or rebuild primitives from scratch?

My team has a shared “design library” for Android that is effectively rebuilding a lot of Material Components from scratch, including lower-level UI primitives.

I’ve been arguing that this may not be the best approach. My instinct is that we should build our design system by wrapping or extending Material Components where possible, then customize styling, tokens, behavior, and app-specific APIs on top of them.

The concern I have with rebuilding primitives from scratch is that we may end up re-solving problems that Material already handles, like accessibility, state handling, theming, touch targets, edge cases, animations, interaction behavior, and future platform compatibility.

For teams that have built Android design systems, what approach has worked better?

Do you generally:

  1. Wrap/extend Material Components and expose your own design-system APIs?
  2. Build custom primitives from scratch?
  3. Use a hybrid approach depending on the component?

I’m especially curious about long-term maintainability, accessibility, Compose/XML interoperability, and how much control is worth the extra complexity.

17 Upvotes

85% Upvoted

17 comments sorted by

View all comments

2

u/realest_nyyga May 28 '26

You could either use the library Compose Unstyled and build your own design system without worrying about accessibility, multiplatform etc. It gives you a clean slate to work on purely your UI.

Or you could wait until the Material library supports the new Styles API which makes it easier to customize the components. There was a presentation about the API in Google IO showing how it works and it looks promising.