Multi-End Code Reuse and Componentization in Meituan Waimai iOS

Meituan Waimai has grown rapidly since 2013, reaching a daily order peak of over 20 million by May 2018. This scale demands high‑stability services, high availability across the whole chain, and faster development cycles for multiple entry points.

The platform evolved into a traffic hub, requiring standardized base capabilities and cross‑team, cross‑region collaboration. Multi‑end reuse therefore targets two dimensions: (1) multiple iOS entry points (the standalone Waimai app, the Waimai channel inside the Meituan app, and the Waimai channel inside the Dianping app) and (2) shared foundational services (location, login, networking, UI utilities, etc.) used by various business lines.

Componentization is a prerequisite for multi‑end reuse. Simply splitting code into CocoaPods without a clear layered architecture leads to larger binaries and complex dependencies. Meituan adopted a progressive‑plus‑planned design: evolve the architecture iteratively while keeping a strategic plan for future extensions.

Key terminology includes Waimai (the standalone app), Channel (the embedded channel), Special (the transitional repository that extracts business code from the app), and “sinking” (moving shared code to lower‑level libraries).

The evolution moved from a low reuse rate of 2.4% to 84.1% by extracting business logic into independent components, separating the shell project, and gradually migrating code to Pods and SubPods. This involved three phases for each module: translation (copying code), sinking (decoupling into lower‑level pods), and re‑integration (referencing the sunk module via pod dependencies).

To handle differences between endpoints, three strategies are used: runtime or compile‑time macros for small variations, a glue layer with protocols for method‑level differences, and file‑level preprocessor splits for larger divergences such as distinct WebView implementations.

A middleware flattening step consolidates shared components into a platform adaptation layer, providing uniform interfaces and hiding endpoint‑specific logic. Dependency conflicts are mitigated by maintaining a single version set in the adaptation layer and flattening the dependency graph using a custom podspec source that removes transitive dependencies.

Build efficiency is improved by offering binary .a pods for fast compilation while retaining the ability to switch to source code for debugging. Different configurations (debug, release, dailybuild) are organized under separate directories.

The supporting toolchain includes:

OClint scans of compile_commands.json for early dependency analysis. binary_pod.rb script to toggle between binary and source pods. sync_podfile for centralized version management. Podfile.patch for one‑click source/binary switching.

Before/AfterPod scripts to filter dependencies.

Git squash for consolidating similar commits.

MTPR tool for automated PR creation.

Jenkins jobs for pre‑merge checks.

HyperLoop platform for one‑click releases.

Atomic diff tool that aggregates commit messages and code diffs across all component repositories.

Reflections indicate that high reuse dramatically reduces duplicated effort but shifts some load to QA. Effective communication among PM, RD, and QA, along with automation of repetitive tasks, is essential for sustainable development.

Author: Shang Xian, senior iOS engineer at Meituan, leading the iOS platformization team since 2015.