Сегодня работаю кросс-функциональным архитектором, пишу больше на Go, но Swift люблю, понимаю Swift Runtime/LLVM + эти знания помогают понимать Rust. Я с 2015 года регулярно участвовал в проектировании мессенджеров — бэкенд и мобайл, даже делали аналог мессенджера запрещенной соцсети на MQTT + Thrift с кодогенерацией. И хорошо понимаю проблемы масштаба крупных мобильных проектов.

В быту Telegram использую по максимуму — Premium, 1000 чатов под завязку, баги ловлю каждый день на iPhone 17 Air и iPad Pro 12.9 с M2. По выходным собираю архитектурные стат-анализаторы кода. Swift-овый отлаживаю прямо на кодовой базе Telegram для iOS.

Что происходит?

Почему?

Потому что 86% кода написаны на Swift, но разработчики мыслят все еще в парадигме ООП.

ООП в Swift — это не просто устаревший стиль, это потерянная производительность.

Swift — не Java и не Kotlin. Это язык, архитектура которого буквально заточена под Protocol Oriented Programming. При компиляции SIL (Swift Intermediate Language) умеет убирать косвенную диспетчеризацию, инлайнит вызовы, специализирует дженерики. И лучше всего это работает если вы пишите в парадигме Protocol Oriented Programming.

На небольших проектах POP или ООП не особо незаметно, когда как на гигантских это треть производительности приложения.

Насколько бы лучше работал телеграм с 80%+ POP:

• от 10 до 25% лишнего CPU-оверхеда из-за медленной диспетчеризации через Virtual Table там, где мог быть Direct Dispatch

• +20–30% к памяти из-за ненужных аллокаций в куче вместо value-типов

• Фреймрейт в горячих User-флоу вырос бы минимум на треть при переходе на POP

• Крэшей стало бы меньше — просто потому что исчезла бы часть неожиданных мутаций shared-состояния

Проблемы производительности идущие от ООП в Swift:

1. Virtual table когда этого можно избежать. Каждый вызов метода через иерархию классов — это в 3-4 раза дороже по времени CPU чем Direct-диспатчеризация. POP + дженерики позволяют компилятору больше использовать Direct.

2. Ссылочный хаос и shared состояния. Классы передаются по ссылке. Два модуля держат один объект и тихо меняют его состояние. POP со структурами даёт явную семантику копирования — без магии, без неожиданных сайдэффектов.

3. SOLID способствует появлению God-классов. ООП это стимулирует архитектурно. ChatControllerImpl на 11К строк, loadDisplayNodeImpl() на 4.2К строк — закономерный исход, когда парадигма ООП поощряет концентрацию логики.
Я понимаю, что про просто декомпозировать ChatController нельзя, это усложнит разработку, но здесь можно реализовать через «протоколы-способности» из POP.

4. Лишние аллокации. Когда бизнес-логика тянется в классы по привычке, а не по необходимости, каждый вызов — лишнее выделение в куче, лишняя работа ARC.

5. Автоматизация тестирования становится адом. Чтобы замокать один класс в середине иерархии, нужно поднять всю цепочку. В POP каждый протокол мокается отдельно.

Отдельно про ...Impl

Постфикс Impl — это окаменелость из мира Java 90-2000-x: один интерфейс = одна реализация. В Swift это не только бессмысленно, но и вредно.

Протокол в Swift — не интерфейс из Java. Это описание способности, а не места в иерархии. Когда у протокола есть ровно одна реализация с суффиксом Impl — это почти всегда симптом: протокол создан по привычке, а не осознано с пониманием специфики языка и платформы.

1. Перепроектировать UI-компоненты — заменить крупные иерархии (ChatControllerImpl, PresentationGroupCallImpl) на протоколы с ассоциированными типами и структуры. Компилятор сможет специализировать код и убрать лишние диспетчеризации.

2. some Protocol вместо классов-обёрток — some фиксирует конкретный тип на этапе компиляции, полностью статическая диспетчеризация, как у структур.

3. enum с ассоциированными значениями — там, где сейчас полиморфные классы с двумя-тремя вариантами (ChatLocationInfoData и подобные), enum справится лучше и дешевле.

4. Протоколы с associatedtype и default extensions — переиспользование кода без дублирования, и компилятор получает полную информацию для оптимизации.

5. Зачищать ...Impl — каждый найденный …Impl должен стать либо структурой с несколькими мелкими протоколами, либо исчезнуть, если протокол создавался только ради него.

   

Swift уже умеет давать почти C-образную производительность с использованием POP. Telegram, при всём уважении к масштабу работы, теряет около 25% производительности — просто потому что команда проектирует на Swift как на Java: из-за превычек и образа мышления которому учат у нас в каждом университете.