App Factory Architecture and Practices at 58.com

58.com’s journey in mobile development began with a single‑team, single‑APP built in 2010 using a classic MVC pattern, then progressed to a multi‑team parallel development model as user volume grew, and finally to a multi‑APP strategy supporting vertical innovation and business mergers.

App Factory Background

The App Factory aims to standardize capabilities, accelerate development, support rapid generation of new apps, and enable vertical business migration across multiple apps. Standardized components such as React Native SDKs, network libraries, and cache libraries are kept independent of business code.

Architecture Overview

The factory architecture consists of two layers: an entry project layer and a pod‑pool layer. The pod pool contains various components (pods) that provide business modules and common services. Pods are categorized as:

Entry Pods : configure code generated by the factory.

Business Pods : contain specific business modules (e.g., real‑estate, recruitment).

Business Middleware Pods : business‑related middleware used only within a single app.

Standard Middleware Pods : generic middleware (e.g., network, hybrid framework) shared across apps.

Base Libraries : third‑party or internal SDKs without dependencies on other pods.

Dependency Rules

1) Upper layers may depend on lower layers, but lower layers must not depend on upper layers. 2) Cross‑layer dependencies are allowed (e.g., business pods may depend on base libraries). 3) Business pods must not depend on each other. 4) Middleware and third‑party pods may have one‑way dependencies only.

These rules ensure clean decoupling when generating or migrating apps.

Tools for Dependency Management

The team built a podFilesDict scanner that records all files in each pod, then parses import statements to map header files to their owning pods, producing a podDependDic used to update podspec dependency sections.

Additional tools detect dependency pollution in standard middleware by checking import styles ("A.h", "<XXX/A.h>", "<A.h>") against a whitelist, and identify circular dependencies among business middleware using a directed‑graph DFS algorithm.

Incremental Compilation Workflow

A global list tracks each pod’s last compiled commit ID. For each build, the system compares the stored commit ID with the latest one from the server; only pods with changed commits are re‑compiled, reducing build time and resource usage.

Vertical Business Migration Example

To share rental and second‑hand housing features between 58 APP and Anjuke APP, the vertical business code and its dependent base libraries were extracted into independent pods, ensuring no coupling with app‑specific code and adhering to the factory’s layering and dependency principles.

Innovation Apps

The factory also supports rapid creation of innovation or “quick” apps (e.g., 58 APP recruitment, rental, second‑hand car) by selecting required pods from the pool, adding any missing functionality as new pods, and configuring them via Podfile and podspec files.

Conclusion

The App Factory provides a proven solution for managing multi‑APP ecosystems, enabling efficient vertical business migration, reducing code duplication, and accelerating innovation while maintaining strict dependency hygiene.