Kotlin idioms to best serve your Design System with Compose

When building a piece of software or a framework that is going to be used by others, it is necessary to think of API Design! Having a simple yet efficient API allows the developers to easily integrate your tool in their apps. And this applies to Compose when you are building a shared Design System. During the session, we'll see how you can take advantage of the best Kotlin idioms to build the right API for your Compose Design System. We'll explore multiple iterations to show how to build components and see the pros and cons of each one.

Transcript

1. 1 The Power of Conversation aircall.io Kotlin idioms to best serve your Design System with Compose Julien Salvi - Android GDE | Android @ Aircall DevTalks Romania 2025 󰐬 @jusalvi.bsky.social
2. 2 The Power of Conversation aircall.io Bonjour ! Julien Salvi Android @ Android GDE “Android dev in shorts!” @jusalvi.bsky.social
3. 3 The Power of Conversation aircall.io Design System & API Design Kotlin idioms x API Design Wrap-up time! Summary
4. 4 The Power of Conversation aircall.io Design System & API Design 🎨
5. 5 The Power of Conversation aircall.io Consistency across UI Why a Design System? 1 2 3 Better productivity Seamless iteration Ensure a uniform look and feel across the app with reusable components and standardized styles, making maintenance and scaling easier. Streamline development with predefined, customizable components, reducing the time and effort needed to build and update UI elements. Quickly adapt to design changes with Compose declarative approach, enabling faster iterations and real-time previews during development. “Because it’s coooool!”
6. 6 The Power of Conversation aircall.io Compose Cookbook Screen 100% Compose
7. 7 The Power of Conversation aircall.io Enhancing Developer Experience (DevExp) Why API design? 1 2 3 Improving code maintainability Increasing reusability Well-designed APIs simplify the development process, making it easier for developers to understand, use, and integrate different components, leading to higher productivity and satisfaction Clear and consistent API design reduces the complexity of the codebase, making it easier to maintain, debug, and extend. This ensures long-term sustainability and flexibility. A well-thought-out API design promotes the creation of reusable components and modules, enabling developers to build applications faster and with greater consistency across different projects. “Because you’ll feel cooool!”
8. 8 The Power of Conversation aircall.io From a simple Material2 button…
9. 9 The Power of Conversation aircall.io …to a fully styled Compose button
10. 10 The Power of Conversation aircall.io Let’s see how we can take the best of Kotlin to design the API of our Compose DS 🚀
11. 11 The Power of Conversation aircall.io Kotlin idioms x API Design 🔬 󰳘 A Kolin x Compose love story
12. 12 The Power of Conversation aircall.io “ ” Kotlin idioms for Compose
13. 13 The Power of Conversation aircall.io Naming @Composable
14. 14 The Power of Conversation aircall.io Default Arguments
15. 15 The Power of Conversation aircall.io Default Arguments
16. 16 The Power of Conversation aircall.io Higher-order functions
17. 17 The Power of Conversation aircall.io Delegated properties
18. 18 The Power of Conversation aircall.io Scoping & receiver
19. 19 The Power of Conversation aircall.io Destructuring data classes
20. 20 The Power of Conversation aircall.io Operator overloading
21. 21 The Power of Conversation aircall.io Infix function
22. 22 The Power of Conversation aircall.io Kotlin idioms • Here are the main Kotlin idioms you should keep in mind when working on the API of your Composable: ◦ ✅ Use default and named arguments ◦ ✅ Be consistent with Composable naming ◦ ✅ Modifier should be exposed in your Composable ◦ ✅ Prefer stateless and controlled @Composable functions ◦ ✅ Properly scope your @Composable
23. 23 The Power of Conversation aircall.io “ ” Advanced Compose API Design
24. 24 The Power of Conversation aircall.io Before creating components • Make sure there’s a single problem the component solves. • Split components into subcomponents and building blocks until each solves a single problem users have • Make sure you need a component and it brings value that justifies the long term support and evolution of its APIs
25. 25 The Power of Conversation aircall.io Do you need a Component? • There has to be a strong reason for it to exist. Lower level components should solve a real problem that users have. • Try to create a Component from the publicly available building blocks. This provides the sense of what it feels like to be a developer who needs your component. • If it looks simple, readable and doesn’t require hidden knowledge to make - this means users can do it themselves
26. 26 The Power of Conversation aircall.io Component or Modifier? • Make a component ◦ If it has a distinct UI that cannot be applied to other components or if the component wants to make structural changes in the UI. • Make the feature to be a Modifier: ◦ If the bit of functionality can be applied to any single component to add extra behavior.
27. 27 The Power of Conversation aircall.io Parameter vs Modifier? • DO NOT introduce optional parameters that add optional behavior that could otherwise be added via Modifier. • Parameters should allow to set or customize the behavior that exists internally in the component.
28. 28 The Power of Conversation aircall.io “ ” Iterating the API design of a component
29. 29 The Power of Conversation aircall.io OK remember that slide?
30. 30 The Power of Conversation aircall.io Let’s see how we reached that API for our buttons 🔘
31. 31 The Power of Conversation aircall.io To style the button we can just call the different styled functions We need to style our buttons, let’s expose ButtonStyle class
32. 32 The Power of Conversation aircall.io We can now build the Composable for the different type of buttons
33. 33 The Power of Conversation aircall.io It was a good start but wanted to have a better API for styling
34. 34 The Power of Conversation aircall.io Having a Style builder could improve the way define the different styles
35. 35 The Power of Conversation aircall.io And this could be done for every components (TextField, CompoundButtons…) So we’re good? well not yet 😅
36. 36 The Power of Conversation aircall.io Our latest iteration, less permissive in style but less error prone
37. 37 The Power of Conversation aircall.io API Design • Here are a few things you should keep in mind when working on the API of your design system: ◦ ✅ It should be easy to use now and after ◦ ✅ It should be understandable by everyone ◦ ✅ It doesn’t have to be perfect! ◦ ✅ Make it scalable ◦ ✅ Don’t hesitate to challenge and experiment
38. 38 The Power of Conversation aircall.io Wrap-up time! Key takeaways
39. 39 The Power of Conversation aircall.io Key takeaways Why the API design matters? • Improve the developer experience • Having a better productivity • Easier app development • Consistency across all component APIs. • Kotlin offers great idioms to achieve a good API Design • Keep experimenting!
40. 40 The Power of Conversation aircall.io Compose documentation https://developer.android.com/develop/ui/compose Compose Component API Guidelines https://github.com/androidx/androidx/blob/androidx-main/compose/docs/compose- component-api-guidelines.md Design systems in Compose https://developer.android.com/develop/ui/compose/designsystems Composing an API the *right* way https://www.droidcon.com/2023/11/15/composing-an-api-the-right-way/ Design Scalable Compose APIs https://io.google/2024/explore/7c08e61e-27d6-4f6a-93fd-590145e83b90/ Resources
41. 41 The Power of Conversation aircall.io Multumesc ! Enjoy the Compose world! Julien Salvi - Android GDE | Android @ Aircall DevTalks Romania 2025 󰐬 @jusalvi.bsky.social