Подборки докладов от компаний про BDUI

Можно сказать, что BDUI становится все популярнее. Но уже понятно, что реализация и опыт у всех компаний разные.

Первое, сильно отличается градус интереса и награды, когда ты разработчик BDUI, а когда потребитель. Многие считают, что разрабатывать саму технологию интереснее и выгоднее. А просто верстать экранчики уже скучнее. В целом для справедливости, в нативе также)

Второе, у всех свои велосипеды. Одни просто перекладывают JSON'ы в монолите и теряют инженерную культуру. Вторые делают полноценые микросервисные архитектуры и свою среду разработки. Я даже встречал инженеров кто устал красить кнопки в iOS и искренне полюбил BDUI.

Не все так однозначно. Разрабатывать BDUI еще сложнее чем на нем писать.

💚Beduin v2: Backend-Driven UI
Честно говоря, мне как инженеру не нравилось писать на бедуине в авито. И до сих пор считаю что в яндексе я за год делал задачи интереснее, чем в авито за три.

И я согласен с комментаторами из авито, в одном из постов, что инженерная культура сильно снижается у такого подхода. Ты становишься экспертом местного велосипеда. Потребитель такой реализации BDUI скорее становится не мобильным разработчиком. А уже бэкендером или манагером. Плохо ли это? Ответа у меня пока нет.

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

📦 Сравниваем нативную разработку и BDUI | Рустам Кенджаев, Яндекс Маркет
Насколько я слышал, у маркета почти не осталось нативных разработчиков. Это мне говорил интервьюер на собесе. На мой вопрос "А зачем вы тогда спрашиваете платформу по iOS?" он дал справедливый ответ: "Если разработчик знает хорошо свою основную платформу, то также разберется и в другой".

Остальное можно оценить по докладу.

🥰 Дмитрий Жердев — BDUI – удовольствие или боль?

Доклад циана один из самых справедливых. Здесь не только поднимаются темы для адопшена фичи и поднятия метрик заинтересованной команды разработки, но и разбор минусов и плюсов. Мне кажется, один из самых честных докладов.

😎 Ускорение приложения с помощью Size, Stride, Alignment в Swift

В нашем чате недавно был спор.

Мы разделились на два лагеря: один лагерь говорил что знания про Size, Stride, Alignment, Side Table — непрактические и в реальной жизни есть более важные знания и практики. Другие говорили, что с помощью таких знаний можно сильно забустить апку.

Я решил проверить и с помощью нейросети накидал пару примеров:
- Декодинг 10к товаров
- фильтрация в 500к элементах
- создание 200к событий аналитики

Результаты выглядят так:
1️⃣ JSON Декодинг (10K товаров).
Было 17.9 ms, 468 KB. Стало 15.8 ms, 312 KB
Ускорение: 1.1x
Экономия памяти: 156 KB

2️⃣ Фильтрация массива (500K товаров)
Было: 56.5 ms, 23437 KB
Стало: 44.1 ms, 15625 KB
Ускорение: 1.3x
Экономия памяти: 7812 KB

3️⃣ Запись аналитики (200K событий)
Было: 71.3 ms, 9375 KB
Стало: 70.5 ms, 7812 KB
Ускорение: 1.01x
Экономия памяти: 1563 KB

Сильно критичного буста я не вижу. А вы как считаете?

Ставь 🖤 если считаешь глубокие знания про память обязательными и 💀если это скорее приятное дополнение

💎 Новый раздел "Perfomance"

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

В этом разделе мы собираем самые важные советы по ускорению приложения. От новичка до профи.

Раздел будет обновляться.

🟣Доклады
🟣Статьи
🟣Реальные свои и чужие практики
🟣Чеклисты
🟣Методы дебага

Получить доступ можно 💰тут или ⭐️ тут

🗺 Как устроена разработка в Яндекс Картах feat iOS Makes Me Hate

Подгон вам на пятницу 13

Помните я проводил опрос в канале за лучшее приложение Яндекса? Тогда победили Яндекс.Карты.

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

Поговорили почти обо всем, о чем вы хотели спросить:
- Как iOS разрабы влюбились в Kotlin Multi Platform
- Самые сложные задачи в продукте
- Модуляризация и архитектура
- SUI vs UIKit
- Онбординг, культуру, фичи
- BDUI
- Offline

И много чего другого. Ставьте лайки и пишите комментарии.

Провел лекцию в ВШЭ.

Назвал доклад "BDUI: Будущее или скам?".

Такой бы доклад наверное не пропустила никакая конфа.

Собрал мнение ~100 разрабов. Сформулировал свой опыт. Собрал открытые материалы.

И даже ответил на свои личные вопросы.

Решил подойдти непредвзято.

Основной вывод: это идеальный инструмент на бумаге для еcom и банков, где легкая и простая верстка, но в больших обьемах. Для сложных приложений со сложным лайаутом это скорее вредно.

Забавно, как у меня порвалась жопа. В прямом смысле. Когда сел в такси порвалась матня. Я решил это символично. Но лекцию не перенес :)

Ставь 💀если скам. Или 🔥норм.

🤖 Подборка полезных аи-настроек для вашего проекта

Настройка для проекта сабагентов, правил, промтов и других md файлов — это супер горячая тема. Не уступающая по холливарам архитектурам и стайлгайду.

А не редко такие описания для агентов являются и хорошей документацией для кожанных мешков.

Я решил чуть углубиться чего же напридумывали уже. И разделил по разным группам настройки:

1️⃣ CLAUDE MD Mobile Development

Главная память проекта. Обычно агент подхватывает правила при старте и ориентируется на них.

2️⃣ Claude Code CLI - Complete iOS Development Setup Guide

Огромный гайд как настраивать Claude Code для iOS проекта. От описания арх рекомендаций, до выбора технологий и тестов.

3️⃣ Cursor Swift Rules

Лаконичный набор правил для курсора. Ничего лишнего.

4️⃣ Claude Code Skills for Apple Platform Development

Коллекция разных скиллов от написания кода для iOS/MacOS. До дизайна, продукта и публикации в App Store.

Делитесь своими полезными настройками

🫣 Способы решения работы с большими данными: Оценка пропускной способности

Продолжаю серию постов про управление нетворк трафиком. В первом посте мы поговорили про проблему наивной предзагрузки. В этом поговорим про оценку пропускной способности.

Пропускная способность (throughput) — сколько данных система способна обработать за единицу времени.

В мобилке ПС можно найти в таких местах:
🟣Загрузка данных по сети
🟣обработка большого JSON'а
🟣запись в локальную базу
🟣рендеринг большого кол-ва элементов

В больших система многое решается на уровне контента. Уменьшаем размер ответа. Кол-во байтов. Строк. Но есть еще супер базовые советы: Пагинация и lazy loading. Кэширование. Чанканизация.

Но хочется поговорить про необычные и непопулярные решения.

1️⃣ Codable + Chunk Parsing

Проблема: если сразу отдавать огромный массив JSONDecoder.decode(...), то он занимает много памяти и времени. Можно разделять JSON на части и парсить кусками

2️⃣ Сжатие данных (gzip vs Brotli)

Похожее делали в авито и других крупных компаний. Такое сжатие может дать до 65% уменьшения ответа.

3️⃣ Прерасчет лайаута и частичный рендеринг

Проблема: бэк отдает очень большой список компонентов. Мы не хотим рисовать сразу все. А остальные компоненты подготавливать в фоне вместо с отрисовкой.

У таблиц есть UITableViewDataSourcePrefetching еще известный в этой статье. Это помогает подготовить данные до появления ячейки и еще отменить загрузку при быстром скролле.

А у SwiftUI я нашел только какой-то костыль. Если найдете норм решение — кидайте