Проблемы доставки фич в больших проектах

Если у вас scrum/agile и прочее, то как у вас таск/юзер стори может быть длиннее спринта (так, что нужно долго держать бранч)?

Релиз фичи зависит от множества факторов:

1. Готовность бекенда, который на стороне банка
2. Готовность инфраструктуры банка к релизу этой фичи
3. Апрув от сторонних проверяющих организаций
4. Смена повестки в банке.

Разработка фичи заканчивается вместе со спринтом, но это не значит, что она может пойти в релиз.

ну и если нельзя добавить фичу, не внеся опасных изменений в остальные куски кода — это не очень хороший код.

Любое изменение кода может нести в себе импакт.

Проблемы взаимодействия с внешними командами на больших проектах

Согласен с тобой, но это уже что-то из запредельного. К сожалению столько времени на outsource проектах не бывает.
Но наши дизайнеры используют invisionapp, в случае если есть необходимость показать кликабельный прототип какого-то флоу заказчику на этапе согласования дизайна. Конечно круто было бы делать это всегда, закрывает кучу вопросов, но как обычно все во время упирается.

Проблемы архитектуры в больших проектах

Да, конечно. В этом репозитории можно найти полноценный тестовый проект, в котором реализован UITabBarController и выстроена полноценная навигация