A Year-Long iOS Modularization Journey - 2. Component Module

To finish feature module separation, we first had to isolate the UI components that were commonly used across multiple screens. There were many entangled components like carousels, header views, and banners, and without cleaning up this layer, feature-level separation kept getting blocked.

In a server-driven structure, it wasn't easy to see at a glance what components existed in the app, and checking whether a similar UI already existed required asking people or digging through both server specs and code together. As a result, similar components were created redundantly, and even checking reusability incurred significant communication costs.

The QA scope was also unclear. Modifying one component often had ripple effects on other components sharing the same common View, header, or carousel, but it was hard to quickly determine which screens needed to be checked.

The separation was carried out based on the UICollectionViewCell + CellViewModel structure. Since we had already separated common dependencies like models, Repository, and LogService into ZCore, the Component module work could be organized into a flow of moving related files to ZComponent, adding public to the necessary types, and then adding import ZComponent at the usage sites.

For review efficiency, we also split up the commits.

• Dependency cleanup commit
• File move commit
• public and import cleanup commit
• Actual logic change commit

Splitting it this way let Git recognize renames well, and allowed reviewers to distinguish moves from actual logic changes.

To improve visibility in the server-driven environment, we also created a ZComponent demo target. The demo app renders only the components, independent of the server, and stores each component's model data as JSON cases so that state and option combinations could be checked quickly. As a result, iOS developers, server developers, and designers could all use it like a component catalog.

Finally, we introduced snapshot testing to visualize the scope of impact. By connecting uber/ios-snapshot-test-case with CI/CD, we made it possible to see via images which components actually changed in a PR, and QA could receive those results immediately.

In summary, this work solved three problems. It created the foundation for feature module separation, improved component visibility in the server-driven environment, and made it possible to clearly share QA impact scope through images.