an article by Hannah Olukoye
Rebranding an app is no small feat, especially when it involves overhauling the design, implementing a dark theme, and addressing years of technical debt. To understand the challenges, strategies, and lessons learned during our recent rebranding phase, I sat down with one of our Android architects, who shared the team’s experience navigating this transformative project.
Q: How did the rebranding affect the existing theming architecture, and did it require any major refactoring?
The rebranding wouldn’t have been possible without prior refactoring. Before this, there was no clear structure or guidance on styling components, which also prevented us from enabling dark mode in the Android app. We had too many redundant styles, along with legacy and custom UI components that were inconsistent.
One of the first steps was to dissolve these legacy components and adopt Material Components. This allowed us to consolidate patterns, such as applying consistent styles to contact form inputs. We also established a proper definition of styles and themes in the app, creating distinct files for specific components and aligning our terminology with the Design System. This made it easier for developers to translate Figma designs into Android layouts.
Each component was tackled individually — new styles were applied, and old, unused ones were removed. I also communicated with the team about which styles to use and how to implement them. Sometimes, this required layout changes to make the new styles work, which turned into a bigger effort than I initially expected. Interestingly, I ended up reducing technical debt from 8 years ago in the process. (Impressive!)
The rebranding itself was the final step and took only two weeks to implement once the base refactoring was done. While some adjustments and corrections were necessary, the effort was minimal compared to the groundwork we laid beforehand.
Q: What architectural decisions guided your theme implementation strategy, especially regarding modularization, reuse, and support for feature-based theming?
From a modularization perspective, not much changed. We already had our Android resources centralized in a single module accessible to all feature modules. While text and icon assets are often feature-specific, we decided to keep everything in one place.
A key decision was adopting a clear naming scheme to distinguish components, types, and themes while differentiating our style definitions from those inherited from the Material Components library. This naming scheme followed the Design System conventions, making it easier to maintain consistency.
By default, we apply base definitions to components and set specific attributes directly rather than creating additional styles, which had previously cluttered our style definitions. When custom changes are necessary, they’re extended within the feature module while adhering to the same naming scheme.
Consistency was key. Hardcoded values, especially colours, were avoided to ensure support for dark mode and dynamic themes. Developers used token-based definitions tied to system settings. I also reduced icon assets by consolidating them and applying consistent tinting, replacing previously duplicated, hardcoded versions. Special design requests were evaluated collaboratively to see if they could align with the Design System. Simplicity remained our core principle.
Q: How did you test theme behaviour across different devices, screen sizes, and Android versions? Were there any tricky bugs or edge cases?
For development, I primarily tested on one emulator with standard settings. Since we use Material Components, I assumed changes would work similarly across older Android versions for individual components. For larger changes, I tested on older versions and tablets as well. I also went through layouts multiple times, testing repeatedly since components were tackled one by one.
UI tests helped ensure functionality wasn’t broken, and I relied on the Android chapter to test changes in their respective feature areas. Before releases, I used BrowserStack to test on a variety of devices.
That said, there were challenges. Some widgets, like content cards, weren’t fully updated or cleaned up, which caused issues when testing dark mode. Problems with background colours and missing tint colours were common. Dialogs were particularly tricky — there were many types, each with different implementations and styles, which required significant effort to fix.
Custom implementations, such as spans or UI inflated in code instead of XML, were another pain point. Finding these usages and ensuring proper styling often required adding extra code. Despite these challenges, properly migrated components worked fine.
Q: What key lessons or best practices did you learn from this redesign, and what would you do differently if starting from scratch?
One of the biggest lessons is the importance of early involvement with UX. Understanding what’s coming and getting an initial sense of task complexity helps immensely. Close collaboration with UX throughout the project is also invaluable for resolving unexpected issues or missing assets.
Another key takeaway is to stick to defaults. Use what the platform and design library offer rather than working against them. This not only ensures backward compatibility but also improves accessibility.
Regularly updating to the latest versions of libraries is crucial. It fixes bugs and introduces new features that can enhance the app. Additionally, having a clear set of defined styles applied consistently across the app is a must. When changes are needed, they should be made in the base style, so all components are updated simultaneously.
If I were starting from scratch, I’d likely use Compose from the beginning. While it’s just a different approach to styling, the same principles around themes, styles, and components would still apply. Compose offers a more modern and flexible way to build UI, which could streamline the process further.
This rebranding effort — along with the introduction of dark theme — gave the app a fresh, modern look while laying the groundwork for a more maintainable and scalable design system. The lessons learned and best practices established during this phase will continue to influence and elevate Android development at our company.
You can experience the new design by downloading the mobile.de app on Android and iOS
Many thanks to Thomas Rebouillon for sharing his insights and contributions throughout the rebranding process.
Top comments (0)