2025: Год, когда SwiftUI умер

Мне повезло. На текущем проекте я могу использовать и SwiftUI, и SC, тк минимальный таргет сейчас 16 iOS. Поэтому я могу щупать это прям на многомиллионом приложении с дедлайнами, багами, автотестами и зависимостями.

До сих пор, почти 80% кто разбирает или пишет про эти технологии — никогда не юзали это в реальном проде. Серьезно, вы даже удивитесь как мало реального опыта у тех, кто вещает на конференциях или пишет статьи.

С 2019 года идут слухи, что SwiftUI станет единственным фреймворком. Но мы уже давно пишем, что этого не будет. Всегда на больших проектах будет UIKit + SwiftUI. Что-то одно не заменит другое. Это два разных инструмента.

Вот и автор статьи уверяет, что 2025 год стал поворотным для SwiftUI. Он перестал быть общепринятым выбором.

Основные аргументы автора:
🟣UIKit обновился. Добавился @Observable который убил один из аргументов, что UIKit не реактивен.
🟣Скорость верстки увеличилась с ИИ. Раньше говорили, что на SwiftUI быстрее пишешь код и верстаешь, но ии-агенты обнулили аргумент и теперь скорость везде одинакова.
🟣Ограниченный SwiftUI. Хоть на дворе 2к25, но у SwiftUI до сих пор есть проблемы с производительностью и гибкостью.

Многое из этого мы уже прямо или косвенно обсуждали в SwiftUI System Design Interview

Ну а вы как считаете cтоит ли хоронить SwiftUI?

Ставь 💀 если так и не трогал SwiftUI в проде.

Mobile System Design: Почему важно учитывать размер аудитории

На тренировках по мобильному систем дизайну мы отдельно остановились на вопросе "Почему важно учитывать размер аудитории". Также нам подробно объяснила экс-тимлид Яндекса.

Грубо говоря, это одно из главных требований реального проектирования. Об этом много можно рассуждать, но лучше всего это сформулировано в книгах Mobile System Design и Building Mobile Apps at Scale.

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

Все авторы выделяют такие набухающие блоки:

1️⃣ Один бинарник

Маленькое приложение с небольшой аудиторией может жить даже с херовым кодом. Но при росте аудитории любая ошибка превращается в массовую проблему.

Мобилки не обновляются мгновенно как веб. Если у тебя 500 000 пользователей, у каждого может быть разная версия, и каждая ошибка живет на устройстве долго.

Вывод: глубокое проектирование и четкая система релизов становятся критичными

2️⃣ Чем больше пользователей, тем дороже ошибки

Building Mobile Apps at Scale пишет: с ростом аудитории растет и команда, а значит растет и цена ошибок.

🟣При 100 пользователях: фича может падать 1 раз в сутки, лаги не критичны, можно быстро пофиксить.

🟣При 1 млн пользователей: маленький баг превращается в стихийное бедствие. Ошибочное проектирование хранения данных вызывает коллизии. Плохая работа с сетью может и вообще привести к падению серверов.

Вывод: Чем шире аудитория, тем выше требования к стабильности и предсказуемости.

3️⃣ Масштаб определяет выбор технологий

С ростом аудитории меняются и приоритеты.

Мало пользователей, значит можно выбирать модные технологии.

Много пользователей, то уже важнее предсказуемость, тестируемость, производительность и дешевые в поддержке решения.

Вывод: системы, работающие на миллионах пользователей, почти всегда строятся на простых, проверенных и надёжных решениях.

🌐 Mobile System Design: Мобильный интернет и регионы

Продолжаю серию постов про масштабирование. В прошлый раз мы обсуждали размер аудитории, сейчас про кол-во регионов.

Иногда встречаются крупные приложения, которые при этом работают только в одном регионе. Классический пример — Авито. Изначально он был частью OLX, где действовал простой принцип "одна страна — одно приложение". Отсюда и особенности архитектуры: отсутствие локализации, все тексты зашиты по-русски и в клиенте, и на сервере. Поэтому сегодня для них отдельный вызов — добавить поддержку ориентации и полноценной локализации в продукт, которому уже почти 10 лет.

Есть и другое распространенное заблуждение среди разработчиков будто некоторые продукты практически не имеют конкуренции. Такси, доставка еды, продажи б/у вещей. Кажется, что они существуют сами по себе и могут позволить себе любые архитектурные решения.

На деле все иначе. При проектировании мобильных приложений важно учитывать особенности сети и регионов, где вы ищете аудиторию. Особенно в больших странах вроде России, где покрытие нестабильное, а часть сервисов регулярно блокируется. Где VPN уже что-то обязательное. Или в странах вроде Пакистана, где средняя скорость мобильного интернета значительно ниже, чем в центре Москвы.

Зачем вообще оценивать скорость интернета?

Вы удивитесь, сколько на самом деле зарабатывают международные продукты. Иногда бывает так, что хорошо известное вам приложение под другим брендом или в виде локального клона в другой стране приносит не меньше, а то и больше денег. И вот вы выходите на новый рынок, а заказчик прямо говорит: "Наш конкурент в Пакистане загружает страницу за 4 секунды. Нам нужно сделать за 2".

В этот момент все, что вы тестировали и проектировали на своих дата-центрах, быстрых провайдерах и удобных VPN’ах, нужно переосмыслить под реальные условия этой страны. Потому что продукт будет жить не в вашей комфортной сетевой среде, а в их со своей задержкой, скоростью и ограничениями.

Tjeerd в Mobile System Design подчеркивает:

мобильные приложения — это работа в условиях постоянно меняющейся сети: Wi-Fi > LTE > EDGE > offline > captive Wi-Fi > обратно.

Это влияет на:
🟣архитектуру кеширования
🟣retry / backoff механизмы
🟣error state UX
🟣периодическую синхронизацию
🟣размер загружаемых пачек данных
🟣выбор форматов данных (JSON vs protobuf)

Скорость сети диктует структуру API и политику запросов. Cлишком много мелких запросов, которые убивают слабую сеть и создают network storm для бэка. Быстрый интернет это оптимистичное допущение. Проектировать надо под худший сценарий. Оффлайн режим становится обязательным, а не опцией

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

Скорость сети системное ограничение, которое меняет архитектуру всего мобильного приложения.

А этот опыт с нами сейчас в одной комнате? 🥺

⌨️ Загрузите своё резюме и бот оценит его по баллам, отметит слабые места и даст рекомендации.

А ещё сразу после проверки можно скачать гайд «Идеальное резюме» с подсказками по структуре, оформлению и навыкам. Функция доступна до 10 раз на пользователя.

🔎 Рубрика "Алгоритмы под лупой": SwiftUI Identity vs Value

Понравился пост у ребят, где они разбирали, какие алгоритмы работают под капотом Diiffable. Вдохновившись решил сделать похожую рубрику, но с другим ракурсом. Хочу искать алгоритмы, которые спрятаны там, где мы обычно о них не думаем.

Почему это важно? Во многом наша работа держится на готовых фреймворках, и это нормально. Но когда понимаешь, как именно они устроены внутри, появляется совсем другой уровень инженерного мышления:

🟣Когда знаешь, какой алгоритм стоит за diffing, кешированием или версткой, проще понять, что подойдет для конкретной задачи, а что вызовет проблемы.
🟣Многая магие перестает быть магией
🟣Понимание внутренней кухни помогает не просто "делать, как принято", а осознанно проектировать UI, сеть, кеш, многопоточность.
🟣За каждым лагом стоит конкретный алгоритм: сортировка, диффинг, поиск, компрессия.
🟣На собеседованиях, в архитектуре, в ревью — чем глубже понимаешь механику, тем проще обсуждать решения и объяснять, почему они работают.

По шагам DiffableDataSource решил пройтись упрощенно по Identity. SwiftUI выглядит простым. Меняем состояние и UI апдейтится. Но под капотом работает довольно интересная система сравнения
Она решает два вопроса:
🟡Это тот же элемент интерфейса или новый? Тут идет сравнение View, id, Identifiable, .id
🟡Нужно ли действительно обновлять поддерево View?

Подробнее об этом мы писали несколько постов.

Какие алгоритмы помогают закрепить знания? SwiftUI не раскрывает свои алгоритмы полностью. Их можно собрать по кускам и лишь догадываться. Но есть три опоры, которые очень хорошо помогают понять его работу:

Алгоритм Майерса.
Этот алгоритм основа CollectionDifference. Находит минимальную последовательность изменений между двумя массивами.

Алгоритм Пола Хеккеля.
Используется в старом и забытом IGListKit. Помогает эффективно сравнивать большие списки и почему стабильные id — критичны.

Dependency Graph.
Помогает понять как SwiftUI выбирает минимальный набор обновлений. По сути это то, чем является AttributeGraph.

Полезные ссылки:
- репо DifferenceKit
- A fast and flexible O(n) difference algorithm framework for Swift collection
- Modern cell configuration
- Implementing modern collection views