How to Design a Robust iOS App Architecture: Key Principles and Practices

Reason

Previously I designed most of the second‑generation architecture for the Anjuke iOS app and later summarized my experience. A former colleague asked what aspects I would discuss when describing an iOS or Android app architecture, prompting this article.

Although client‑side architecture can be as complex as server‑side, its focus differs; for example, iOS apps do not need to handle C10K‑type scalability.

This series will concentrate on iOS app architecture, but the ideas are applicable to Android as well.

When discussing client‑side architecture we consider:

Network API calls : enabling developers to invoke APIs safely and ensuring good user experience under varying network conditions.

Page presentation : organizing UI to reduce coupling and simplify business‑side development.

Local data persistence : arranging data locally with minimal performance overhead.

Dynamic deployment : delivering new content or urgent bug fixes without releasing a new version.

Team‑level concerns include:

Collecting user data for product and operations analysis.

Organizing business modules and shared infrastructure.

Automating daily builds for QA testing.

The article outlines a six‑step architecture design method:

Identify the problems to solve and their necessary conditions.

Classify problems into modules.

Clarify dependencies, define module communication standards, and design modules.

Predict future directions, add modules as needed, and record foundational data.

Implement core modules first, then compose the full architecture.

Instrument, run unit and performance tests, and optimize based on data.

Key qualities of a good architect include continuous learning, deep business knowledge, adherence to software engineering standards, and the ability to balance constraints with flexibility.

Good architecture is characterized by clean, well‑organized code, minimal documentation requirements for developers, consistent design philosophy, lack of horizontal dependencies, appropriate flexibility, testability, extensibility, forward‑looking technology choices, few and simple interfaces, and high performance.

The article also discusses layering concepts, noting that three‑layer architectures (presentation, business, data) are common, but actual layer count depends on the logical modules identified during design.

Finally, it warns against using generic "Common" or "Core" folders/pods, as they tend to accumulate unrelated code, increase coupling, and hinder maintainability; instead, favor fine‑grained modules with clear responsibilities.