Why Componentization Is Essential for Scalable Mobile Apps

Introduction

For medium to large mobile apps, componentization is a widely used project architecture. The author shares personal experience, common problems encountered, and insights gained from daily development and discussions with peers.

What Componentization Brings

Problems with a Monolithic Architecture

Multiple co‑existing apps require reusable components.

Increasing feature set leads to larger codebases and higher collaboration costs.

Multiple languages and tech stacks add complexity.

Key Pain Points

Engineering efficiency : Large codebases slow compilation and increase merge conflicts.

Quality issues : Hard to associate commits with features, enforce compliance, and control code permissions.

Component reuse : Need to share basic and business components across apps.

Cross‑stack communication : Navigation and component interaction must work across different tech stacks.

Decoupling : Pages and business components should be loosely coupled to allow flexible addition or removal.

Advantages of Componentization

Code reuse – encapsulated functionality can be shared with minimal dependencies.

Reduced complexity – consumers interact with public APIs without needing to understand internal implementation.

Better decoupling – clear boundaries limit unhealthy dependencies.

Technology isolation – components can use different languages or frameworks without affecting others.

Independent development, maintenance, and release – each team owns its component.

Faster compile/build – binary components are pre‑compiled, reducing build time and errors.

Granular permission control – each component’s repository defines its access rights.

Version management – explicit component versions simplify tracking and rollback.

Challenges in Componentization

Componentization does not automatically solve all problems; new issues arise that must be managed.

1. Component Granularity and Boundaries

Finding a balance between too coarse (tight coupling) and too fine (excessive overhead) granularity is essential. Consider responsibilities, reuse potential, and impact on change scope before splitting.

2. Managing Dependencies

Dependencies can be strong (direct API calls) or loose (notifications, URL schemes, service interfaces). Strong coupling is simple but less flexible; loose coupling adds flexibility at a performance cost. Establish rules for allowed dependencies, direction, and coupling level.

3. Choosing Communication Mechanisms

Common loose‑coupling methods include notifications, URL schemes, Objective‑C runtime, service interfaces, and event queues. Select based on scenario, weighing decoupling, safety, and ease of use.

Practical Guidelines and Principles

Component splitting principles – use layered architecture (foundation, common business, business implementation, app host) to guide placement and dependency direction.

Basic vs. business components – basic components expose APIs directly; business components are accessed via indirect communication.

Third‑party libraries – manage each as an independent component, avoid direct exposure, and encapsulate when possible.

Avoid over‑aggregating public components – only aggregate when the added functionality is lightweight and does not introduce many new dependencies.

Component Dependency Relationships

Prefer URL Scheme for page routing and service interfaces for business functionality; use notifications or RxSwift for one‑to‑many subscription scenarios.

Service Interface Example (Swift/Obj‑C)

// @objc protocol</code><code>@objc public protocol JDCartService {</code><code>    func addCart(request: JDAddCartRequest, onSuccess: () -> Void, onFail: () -> Void)</code><code>}</code><code>// Swift protocol</code><code>public protocol CartService: JDCartService {</code><code>    func addCart() async</code><code>    func addCart(onCompletion: Result)</code><code>}</code><code>// Implementation</code><code>class CartServiceImp: NSObject, CartService {</code><code>    // Implements both Obj‑C and Swift protocols</code><code>}

Centralized registration of services at app launch is recommended to avoid duplicate instances.

Quality Assurance

CI Checks

Third‑party libraries must not depend on other components.

Basic components must not depend on business components.

Business components must not directly depend on other business components.

Avoid circular dependencies and reverse layer dependencies.

Build‑time Validation

Detect missing service implementations or incomplete method implementations.

Flag usage of Objective‑C runtime dynamic calls.

Runtime Monitoring

Report missing routes, absent service implementations, or undefined methods.

Metrics for Component Health

Number of basic component dependencies.

Number of business service dependencies.

Count of erroneous dependency relationships.

Common Issues

Deciding whether a basic component should expose APIs directly or via an interface.

Assessing the need for componentization in small projects.

Transitioning a monolithic project to a componentized architecture.

Extra costs: managing multiple git repositories, versioning, debugging binary components, and maintaining CI/CD pipelines.

Conclusion

There is no perfect architecture; it must evolve with organizational changes, business needs, and team capabilities. Componentization brings scalability and maintainability for large projects but introduces additional overhead that must be managed through clear guidelines, automated checks, and continuous monitoring.