How Youku’s iOS Plugin Architecture Supercharges Build Speed and Modularity

As Youku’s business expanded rapidly, the number of modules grew explosively, creating heavy and tangled direct dependencies that hindered daily development.

Pluginization Results

iOS module pluginization has been fully deployed at Youku, producing lightweight engineering across business lines, with many business and architecture plugins that can be freely assembled according to needs.

Direct Benefits

Significant improvement in business plugin compilation efficiency and drastic reduction of local compile time.

Plugins can be assembled into business plugin projects, supporting simulator compilation, debugging, and hot‑reload.

Both module projects and whole‑package projects use plugins as dependencies, eliminating version inconsistencies and enabling automatic version updates.

Dependency library count is greatly reduced; pods reuse cache, increasing success rate, speed, and reducing disk usage.

Indirect Benefits

Plugins provide checkpoints for runtime memory, app startup, power consumption, maintaining good user experience.

All plugins can be freely assembled via a configuration center, enabling rapid creation of lite, international, Apple Watch, Apple TV apps.

Reduced dependencies improve Swift breakpoint debugging speed.

Packaging efficiency is increased by dynamically generating plugin‑combined installation packages for testing.

What Is a Plugin?

A plugin is a collection of modules that may also depend on other plugins; physically it is a text descriptor file listing its modules and plugin information.

Based on an Xcode project, a plugin can be compiled independently to produce an app artifact and supports free combination of multiple plugins.

A simple plugin may consist of a single module, while a complex plugin can contain multiple modules and other plugins.

# Image library plugin
target 'Plugin' do
    # Module A
    pod 'ModuleA','5.9.4'
end

# Plugin
target 'Plugin' do
    # Image library plugin
    plug '1.ImageLibraryPlugin'
    # webp image parsing module
    pod 'ModuleB','0.1.4'
    # webp core module
    pod 'ModuleC','1.1.0.1'
end

Why Plugins Are Needed

Most teams focus only on the features they are iterating, ignoring others; extracting a single‑business‑function app from the whole package dramatically speeds up compilation.

Decoupling at the module level is costly and risky; by enlarging the decoupling granularity to plugins, only horizontal coupling between plugins needs to be managed, while plugins may depend on lower‑level plugins and internal modules may remain coupled, greatly reducing human effort and simplifying maintenance.

Plugin Usage Guidelines

Aggregation Principles

Business plugins: aggregate modules by business function boundaries.

Common business plugins: aggregate reusable minimal sets of modules.

Architecture function plugins: aggregate middleware modules by minimal functional sets.

Dependency Principles

Business plugins must not horizontally depend on other business plugins; they may depend on lower‑level plugins.

Architecture plugins must not depend on upper‑level plugins; they may depend on lower‑level and other architecture plugins.

Module Ownership Principles

A module belongs to only one plugin and must have a clear function.

If a module is depended on by multiple plugins, consider promoting it to a plugin.

A module can be written as a plugin.

Version Principles

Plugins themselves have no version concept.

The set of modules and versions in an integration area corresponds to those in a plugin.

Modules and versions in a plugin default to the online integration area version, but can be synchronized to the latest or historical integration area.

Low‑Cost Control Scheme

All Youku modules have been pluginized, and a low‑cost control scheme automatically updates plugin content and manages dependencies.

Automatic Plugin Update

Each plugin records module names and versions; during each version iteration, plugins automatically handle module addition, deletion, name changes, and version updates. An automated sync and inspection service provides:

Automatic update of added or removed modules.

Automatic change of module version numbers.

Automatic compilation inspection of all plugins after content update.

Successful inspections merge plugins into the integration branch for business use.

Failed inspections trigger DingTalk notifications with failure details for quick troubleshooting.

Dependency Control

Based on plugin ownership and hierarchy, a standard module dependency data model is abstracted. During module build and packaging, a dependency check gate is added; only plugins passing the check can be packaged.

Results Data

Build Efficiency

Local compilation efficiency of business plugin projects is significantly higher than whole‑package projects, with average time savings evident.

Formula: Build efficiency = (Whole‑package build time – Plugin build time) / Whole‑package build time.

Simulator Support

Previously, some modules prevented the whole package from supporting simulators. After pluginization, non‑simulator‑compatible plugins can be excluded, allowing plugin projects to run on simulators, offering unlimited devices, support for all iOS versions, hot‑reload, and early UI adaptation for new devices.

Disk and Memory Usage

Pluginized projects contain far fewer modules than the whole package, dramatically reducing disk usage. Memory checkpoints provided by plugins enable fine‑grained measurement of runtime memory per functional component (e.g., player, container, danmaku, comments).

Conclusion

iOS engineering pluginization applies a divide‑and‑conquer approach, splitting a complex app into multiple sub‑apps, allowing developers to focus on feature development and user experience while improving issue reproducibility, development efficiency, and overall developer happiness.