2026.09.03 14:20 ~ 15:00 Narwhal

Overcoming architecture generational shifts: Development strategy for a 14-year-old Android app

App Architecture 日本語

In long-running Android applications, the history of architectural adoption and re-architecture builds up in the codebase. Starting from the era of MVC, through the rise of MVP and Flux, to the recommendation of MVVM in architecture guides, there have been many times when widely adopted architectural paradigms shifted. Eight Android also has an accumulation of such history. Our app, whose development began in 2012, has become a mix of multiple generations of architecture. (7 generations, surprisingly!) It is not uncommon for an implementation that was optimal at one point to become a source of cognitive load and a factor that hinders implementation years later due to changes in architecture or adopted technologies. Even classes with similar names and roles may have subtly different responsibilities and implementation policies depending on the generation. When separation of concerns and state management differ depending on the generation of architecture, it becomes difficult for new members to catch up and to identify the impact scope during changes. When developing features for such an app, simply considering the latest architecture is often insufficient. It is necessary to account for distortions and generational gaps with past architecture, and to ensure that current implementations are less likely to lead to future cognitive load. Rather than searching for a permanently correct architecture, it is important to clarify boundaries between architectural generations and establish refactoring practices to localize parts that could become debt in the future. In this session, while referencing architectural patterns actually used in our app, we will share insights gained from running feature development and re-architecture in parallel for a long-operated app. Reflecting on the background of how past architectures were introduced and what points led to difficulty in modification, we will introduce the currently adopted layered architecture, boundary definitions with old architectures, inter-module dependency rules, and setting refactoring scopes within projects and daily operations. Through this session, we hope you will gain insights into thinking about boundaries and rules that should be established to deal with legacy architectures when introducing or operating new ones. (Translated by the DroidKaigi Committee)

Intended audience

- Android engineers, tech leads, and architects involved in the design and maintenance of long-running Android apps - Those who feel challenges in codebases where multiple generations of architecture and technology stacks coexist - Those who want to introduce a new design but are struggling with boundaries with existing designs or migration policies

Sessions in the same time slot

View all sessions