💎 Новый раздел "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 я нашел только какой-то костыль. Если найдете норм решение — кидайте

Нужны ли iOS разработчики?

Сейчас читаю книгу Accelerate: The Science of Lean Software. В нем было исследовано более 23 000 команд. Где главный вывод: высокая производительность связана не с языком или стеком, а с культурой, архитектурой и инженерными практиками.

“We found no evidence that any one technology stack is superior. Instead, what predicts high performance are capabilities.”

В беседе с Яндекс.Картами я задал один из острых вопросов не все разрешили: Нужны ли iOS-разрабы в проекте с KMP?

Ещё пару лет назад на конференциях звучало: будущее за Kotlin Multiplatform. Не учишь Kotlin и пойдешь на мороз. Я понимал это байт.

Меня никогда не пугали другие языки, но такая недружелюбная риторика от евангелистов технологий — отталкивала. Я никогда не был против кроссплатформы для подходящих задач. Но хотелось дать ассиметрию радикальным мнениям. Нельзя заменить одних на других.

Сегодня риторика изменилась. Теперь пугают не кроссплатформой. Пугают ИИ.

Но вопрос до сих пор в воздухе. Что же происходит с командой мобильных инженеров, если есть КМП или другая платформа? Если ли перевес что на 1 иосера теперь 5 андроидеров? Заменили ли кого-то?

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

Кроссплатформа всегда будет развиваться параллельно или даже вопреки нативу. Поэтому тебе нужно держать команды в балансе. С выходом нового обновления или дизайна потребуется знаток и любитель продукции Apple. И наоборот. Но его важноcть определяется не тонкими знаниями, а устойчивостью к изменениям.

А если ваша компания выберет курс "замены одних на других чтобы избавиться от зависимости", то потеряет приближенных к самой платежеспособной аудитории. Ну или к остальным менее важным платформам 😂

Во многих книгах с хорошей базой по построению инженерной культуры пишут — это лучшая инвестиция в быстро меняющийся мир. А не изучение отдельных языков или стэков.