🤫 Что общего у UITableView и git diff

Когда-то давно, лет 10 назад (у меня была задача: получать пачку данных с сервера, находить различия с кэшем и красиво обновлять UITableView, чтобы не было резких reload'ов, а всё плавно вставлялось, удалялось и двигалось.
Тогда задача обошлась мне, не в один день анализа и проектирования, чтобы научиться сравнивать старый и новый массивы.

Тогда ещё не было никакого CollectionDifference, и я просто пошёл реализовывать алгоритм Вагнера–Фишера и работать с вычислением: расстояния Левенштейна и редакционноого предписания - минимального количества действий и их последовательности чтобы из "ABC" получилось "ACD".

Ну и конечно, всё это руками прикручивалось к performBatchUpdates:

tableView.performBatchUpdates {     
  tableView.deleteRows(at: ...)     
  tableView.insertRows(at: ...) 
}

Весело? Не очень. Но тогда по-другому никак.

Потом, с приходом iOS 13 и Swift 5.1, всё изменилось.
Apple выкатили DiffableDataSource, и вместе с ним — CollectionDifference.
Это была буквально революция, теперь можно просто сформировать снапшот и отдать его таблице:

var snapshot = NSDiffableDataSourceSnapshot<Section, Item>() 
snapshot.appendSections([.main]) 
snapshot.appendItems(items) 
dataSource.apply(snapshot, animatingDifferences: true)

UITableView сама всё поймёт, сама вычислит, что вставить, что удалить, что переместить — и сделает это с анимацией.
А мы — просто передаём новое состояние.

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

Apple реализует его для CollectionDifference.
Можно глянуть исходники Swift или вот обьяснение алгоритма.

Но если хочется больше контроля или скорости — есть и альтернативы.
Например, DifferenceKit, который использует алгоритм Пола Хекеля.
Вот сам код.
Он быстрее в ряде кейсов, особенно если много данных, на это влияет сложность O(n), бенчмарки можно посмотреть на gh.
И с ним сделали даже backport - DiffableDataSource для старых iOS.

Мораль истории: задача сравнения последовательностей — стара как мир.
Её решают в UI, в git, в текстовых редакторах.
А теперь и мы — наконец-то — можем делать это в UITableView, не теряя нервы на написание сложных алгоритмов и работу с indexPath-ами.

#L #UITableView #DiffableDataSource #CollectionDifference #LevenshteinDistance

👏

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 раз на пользователя.