Challenges and Improvement Practices for Mobile App Development Teams

With the continued evolution of smartphones, they are now used more as computers than simple communication devices, prompting many traditional PC/M business functions to shift to mobile app development.

The article outlines three typical stages that such app teams experience: a pre‑stage where functions are transferred from PC/M and inter‑team friction often arises; a mid‑stage where accumulated technical debt hampers progress; and a post‑stage where user‑experience‑driven, innovative features demand flexible release planning and minimal coupling.

A detailed case study of an APP team (10 developers across iOS and Android handling six business lines) illustrates common problems: divergent team perceptions, trust erosion, high coupling leading to bulk testing, and delayed releases caused by dependencies.

From this analysis, two main improvement directions are identified: improving inter‑team collaboration and reducing demand‑to‑technology coupling.

For collaboration, the article recommends establishing clear processes, assigning fixed interface owners, and ensuring transparency of milestones, risks, and plans, so that all parties have a shared, visible roadmap.

To lower coupling, it suggests frequent small decoupling actions, limiting the number of teams involved in a single demand, and defining clear testing scopes to avoid large, all‑at‑once test cycles.

The article also stresses the need for a continuous improvement cycle rather than one‑off fixes, advocating for an iterative approach that embeds these practices into the team’s routine.

Later, it proposes a parallel‑version development model where the team splits into two sub‑teams, each working on a separate branch in alternating cycles. This extends the effective development window while keeping user‑perceived release frequency unchanged.

The parallel approach brings several benefits: longer development periods reduce interruptions, allow larger features to be tackled, balance QA workload, and push the need for more mature continuous integration practices.

Finally, the article highlights that when coupling is low, larger strategic moves such as plugin‑style development and board‑based workflow decoupling become feasible, ultimately enabling release decisions to be driven by product, operations, and market considerations rather than technical constraints.