复杂界面设计的实现和样式管理
iOS App最终呈现给用户的是一组组的UI界面，而对于一个特定的App来说，其UI的设计元素（如配色，字体大小，间距等）基本上是固定的，另外，组成该App的基础组件（如Button种类，输入框种类等）也是有限的。但是如何管理，组合，重用组件则是架构师需要考虑的问题，尤其是一些App在开发过程中可能出现大量的UI样式重构，更需要清晰的控制住重构的影响范围。这儿的复杂性本质上是UI组件自身设计实现的复杂性，多UI组件之间的组合方式和UI组件的重用机制。
路由设计
对于一个大型的iOS应用，通常会把其功能按Feature拆分，经过这样的拆分之后，其可能出现的路由有以下几种：
APP间路由： 从其它App调起当前App，并进入一个很深层次的页面（图示1）。
APP内路由：
启动进入App的Home页面（图示2）
从Home页面到进Feature Flow（图示3）
Feature内按流程的页面的路由（图示4）
各Feature之间的页面跳转（图示5）
各Feature共享的单点信息页的跳转（图示6）
根据Apple官方的MVC架构，这些复杂的各种跳转逻辑，以及跳转前的ViewController的准备工作等逻辑缠绕在AppDelegate的初始化，ViewController的UI逻辑中。这儿的复杂性主要是UI和业务之间缠绕不清的相互耦合。
应用状态管理
一个iOS应用本质上就是一个状态机，从一个状态的UI由User Action或者API调用返回的Data Action触发达到下一个状态的UI。为了准确的控制应用功能，开发者需要能够清楚的知道：
应用的当前UI是由哪些状态决定的？
User Action会影响哪些应用状态？如何影响的？
Data Action会影响哪些应用状态？如何影响的？
在MVC，MVVM，VIPER的架构中，应用的状态分散在Model或者Entity中，甚至有些状态直接保存在View Controller中，在跟踪状态时经常需要跨越多个Model，很难获取到一个全貌的应用状态。另外，对于Action会如何影响应用的状态跟踪起来也比较困难，尤其是当一个Action产生的影响路径不同，或最终可能导致多个Model的状态发生改变时。这儿的复杂性主要体现在治理分散的状态，以及管理不统一的状态改变机制带来的复杂性。
