How Didi Scaled Its iOS Architecture: From MVC to MVCS and Componentization

Didi, a leading Chinese internet ride‑hailing platform, has grown from a small startup to a top‑tier internet company, prompting continuous evolution of its iOS client architecture. InfoQ interviewed Li Xianhui, iOS technology lead of Didi’s platform product center, to discuss this evolution.

InfoQ: Please introduce yourself and tell us when you joined Didi. Li Xianhui: Hello, I’m Li Xianhui. I joined Didi in May 2013 and currently lead the iOS team. I have witnessed Didi’s growth from version 2.0 to the current 4.2.5, with the team expanding alongside the business.

InfoQ: What major changes have occurred in the iOS client architecture during Didi’s rapid growth? Li Xianhui: In May 2013 we launched Didi 2.0, switching to MVC for clearer code structure. In May 2014 we introduced a dedicated‑car line (Didi 3.0) and used a state‑machine model, treating each order stage as an independent state to support both taxi and dedicated‑car services. By early 2015 we added many new services (car‑pool, driver‑assist, bus, etc.), which caused severe code coupling and release coordination challenges across teams in Beijing, Hangzhou, and Shanghai. From mid‑2015 to the end of the year we built a component‑based framework called “The One”. Using CocoaPods, we split common functionality into technical and business components (e.g., taxi component, dedicated‑car component). Each business line depends only on shared components, improving modularity and easing future refactoring.

InfoQ: What architecture pattern does Didi’s iOS client use today, and how do you keep controllers lightweight? Li Xianhui: We employ a hybrid MVCS (Model‑View‑Controller‑Store) and MVVM approach. The “Store” handles server APIs, data sharing, and caching, making components stateless and similar to React‑Native + Redux. Controllers are slim because business logic resides in Stores, while ViewModels (VM) further reduce controller responsibilities.

InfoQ: How is componentization organized and implemented? Li Xianhui: Since mid‑2015 we have technical components (e.g., networking, navigation) and business components (payment, login, messaging, location, ads, analytics, sharing), each packaged as an independent CocoaPod. Private Pods are used locally for debugging without committing code. Navigation between components uses an openURL‑based router (ONERoute) that registers URL‑to‑class mappings in +load, allowing decoupled page launches and optional external opening.

InfoQ: What challenges arise when displaying real‑time data for multiple services (taxi, fast‑car, dedicated‑car) and how does Didi address them? Li Xianhui: Challenges include delayed messages (solved with socket long‑connections), high traffic (mitigated by using protobuf to reduce payload size), data integrity (restricting write access to shared data and handling modifications only within Stores), and shared map resources (maintaining a single map instance on the home screen with independent canvases for each service to reduce memory usage).

InfoQ: Do you use hot‑fix technologies, and what is the current practice? Li Xianhui: Didi uses Lua and JSPatch for hot‑fixes; JSPatch is preferred because it is officially accepted by Apple. We are building an internal JSPatch distribution platform that manages scripts, versions, and secure transmission.

InfoQ: How do the iOS and Android teams share code? Li Xianhui: Both teams share the same socket long‑connection library, as iOS and Android run on Unix‑like kernels and can use identical system interfaces. Platform‑specific code follows the same design principles, reducing effort and ensuring consistency.

InfoQ: Has Didi adopted Swift, or are there plans to do so? Li Xianhui: We have not adopted Swift yet because supporting iOS 8 and below would increase the app size (Swift runtime must be bundled). The passenger app is approaching a 100 MB limit, so Swift is not planned for it. The driver app may experiment with Swift in a small pilot next quarter.