wtf? Ждем переезда в Max?

Почему не надо идти в iOS сейчас

Очередное обсуждение что лучше iOS vs Backend для начала карьеры.

Я, как и многие у нас в чате, уже давно советуют идти в иос не ради денег, а по любви.

Тот же бэкенд уже давно обогнал по вилкам мобилки. А ML улетели в космос.

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

Кстати, кто не помнит, то напоминаю. Сейчас заканчиваю последний курс очно-заочного обучения. Учился 4 года на бизнес-информатика. Пришло время выбирать выпускную квалификационную работу.

Сразу побежал смотреть список тем от универа и нашел самую подходящую для меня: "Применение генеративного ИИ для создания персонализированных образовательных программ"

Будем делать ее с научным руководителем. Интересно как эта работа пробустит меня и чему обучают современные программы универов

Покидаю самые интересные инсайты

А вы поделитесь пожалуйста где подобное по теме уже встречали? В курсах, работе, универе?

Записываем нормальный подкаст в нормальном офисе с нормальным светом.

Network: Мобильная связь и квота пропускного канала

Зачем думать о 2G интернете? Ведь далеко не все тестят свои апки в этой сети.

Тема мобильной сети — гиперчувствительная. И при этом сильно недооцененная в мобильной разработке.

Недавно я брал консультацию у core команды Яндекс Плеера о том, как оптимизировать видео. Формально разговор был про форматы, коллекции и устройство плеера. Но самым откровенным и очевидным для меня оказался совсем другой пласт — это нетворк-квоты и приоритизация запросов. Казалось бы, очевидно. Но почему мы не задумываемся об этом?

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

Да, в некоторых крупных компаниях есть платформенные или перфоманс-команды (Авито, Т-Банк), которые глубоко оптимизируют нетворк-слой клиента. Но возникает логичный вопрос: почему обычному мобильному разработчику важно понимать, как работает сеть?

Многие разработчики воспринимают сеть как что-то простое: отправил запрос и получил ответ. В реальности мобильная сеть: нестабильная, медленная, непредсказуемая. Именно поэтому в системном дизайне ей всегда уделяют отдельное место. Игнорировать сеть значит проектировать приложение для идеальных условий, которых у пользователя чаще нет.

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

Начнем с базовых, но очень важных сложностей:

1️⃣ Соединение постоянно меняется

Этот вопрос очень важен. Особенно при звонка, которые должны работать даже из парковки и в лифте. Тот же Zoom удивляет многих как работает стабильно с 3G или плохим интернетом, когда же конкуренты, телега или ватсап, еще до замедлений, работали плоховато.

Здесь множество оптимизаций: от хитрых алгоритмов сжатия, то заигрывания с соединениями.

2️⃣ Высокая задержка (latency)

Есть cold и hot ответы. И чаще ответы CDN или других хранилищ нужно заранее "прогревать". Ведь даже при хорошем соединении холодный старт может быть отдавать первый байт долго.

3️⃣ Ограниченный и дорогой трафик

В некоторых регионах, странах, трафик может быть дорогой. В том же Пакистане интернет в 2 раза хуже РФ, но некоторые сервисы уже получают денег больше, чем у себя в стране. Чтобы конкурировать нужно уметь подстраивать под их сеть и быть быстрее конкурентов.

4️⃣ Нетворк квота устройства

Устройство условно на момент соединения имеет доступную пропускную способность 5 Мбит/с. Это общий канал, которым пользуются все процессы сразу: ваше приложение, системные сервисы, другие приложения в фоне. Под наше приложения нет отдельного канала. Все делят один и тот же ресурс.

Если одновременно идут загрузка видео, аналитика, картинки, обработка данных — все запросы конкурируют за один канал. Видео хочет 4 мб/с, аналитика 0.1 мб/с, апи запросы 0.9 мб/с. Канал полностью забит. Если появляется еще один запрос, то появляются лаги и зависания.

И тут еще сложность, что ОС распределяет ресурсы, а не приложение.

В след постах разберем все детальнее

Network: 2G, 3G, LTE, 5G

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

Иногда 4G может дать больше проблем, чем 3G.

1G
Только голос. В 1G не существовало понятия “скорость интернета” потому что интернета не было.

2G
Во времена какой-нибудь нокиа 3310 это была связь и минимум данных. Скорость была в пределах 100–200 кбит/с

Проблемы: экономия каждого запроса

3G
Расвет мобильного браузинга. iPhone 3G. Социальные сети мой мир, первые фейсбуки и вк. Скорость могла быть на пике до 2–10 мбит/с.

Проблемы: борьба с latency. Первый байт приходит долго. Нужны прогревы запросов.

4G
От 20–100 до 300+ мгбит/с. Покрытие интернета стало массовым. Появились онлайн игры и видеостриминги. Весь трафик перешел из веба в мобилку.

Проблемы: нестабильность сети и появляются потери пакетов. Качество сети прыгает и приходится адаптироваться.

5G
От 100–1000 мбит/с до 10–20 гб/с. Видосы 8к. Автопилоты тачек и роботы. Инфраструктура смарт сити. Мобильный облачный гейминг.

Проблемы: конкурекция за каналы. Один канал делят все приложения. Видео, аналитика, API конкурируют между собой

Каждое поколение сети бросало новые вызовы. В идеале хорошее приложение должно стабильно работать в каждой.

Интересные статьи:
- What are the differences between 2G, 3G, 4G LTE, and 5G networks?
- Exploring Mobile Technology from 1G to 5G
- Ликбез 11-5. Поколения сотовой связи (5G)

Опенсорс-библиотека Implicits от Яндекс Браузера: новый шаг в передаче зависимостей Swift

У коллег из яндекс браузера вышла огромная статья на 49 (!) минут чтения (теперь не говорите мне что мои статьи большие). Много кода и аргументаций зачем пишут свое решение с DI.

Тема DI очень актуальная. Знаю что как минимум 4 компании в этом году занимались переосмыслением и актуализацией своих DI.

Это понятно. Особенно когда у тебя сложный продукт, который стал держать в себе много технологий и модулей: UIKit и SwiftUI для UI слоя. Множество зависимостей и чужих SDK. Кроссплатформы и BDUI.

Почитайте, очень интересно

Подборка статей про BDUI

Хочу сделать глобальный и детальный опрос про использование BDUI. Лично я знаю множество разработчиков с разными мнениями. Кто-то даже использовал данные и опросы из моего канала в реальных докладах. Поэтому будем идти по data driven development. Отбрасывая эмоции, пузыри и слепые догмы. Идем за объективностью.

Но сначала решил собрать самые "честные статьи". И здесь не будет докладов с конференций. Все чаще слышу, что конференции умирают и никто туда не ходит. Почему? Мне отвечают, потому что там мало искренности и правды. Поэтому поищу самые на мой взгляд детальные и наполненные разными мнениями.

1️⃣ Почему BDUI актуален именно сейчас в e‑commerce

Эта статья мне понравилась тем, что можно взглянуть кому именно продается BDUI. А это владельцы е-commerce приложений. А ведь чаще так и есть. Если у тебя сложный лайаут, мессенджер, карты, навигации, то BDUI ложится очень плохо. Но вот если у тебя какой-то маркетплейс, то в целом можно заменить 90% нативщиков.

Вкратце, если вы хотите работать с BDUI, то идите в e-commerce

2️⃣ Server-Driven UI vs Native: Data Sync Speed

Здесь идет классический разбор Server-Driven UI и натива. Особый упор делается, что SDUI сильно зависим от хорошего интернета. Для меня лично является очень странным решением выбирать онли SDUI если у нас в регионах очень плохо с интернетом. Когда же натив лучше работает с оффлайном (некоторые маркетплейсы идут в эту сторону тоже).

Если вам важен оффлайн (мессенджеры, видео, медиа) то тут выбор очевидный — натив. Пусть даже ценой медленного изменения UI.

3️⃣ Пост на реддите "Server Driven UI - is this really worth it?"

На удивление, форумы и чаты, стали новым источником искренности. Туда еще не проник маркетинг и фальш из конференций. Не добралась рука модераторов и программных комитетов, которые обрезают всю неудобность. Что пишут? Много разных мнений. Можно почитать самому.

Этот обзор вы не просили, но я принес

Fucking Approachable Swift Concurrency

Достали занудные правильные документации? Хочется чего-то народного и без цензуры? Устали от корпоративного дресскода?

Если хочешь наконец разобраться в теме и понять все простыми словами, без тяжелого профессионального жаргона, то поможет этот сайт.

Мне, если честно, гораздо ближе такая форма. Прямая, простая, без лишних терминов.

Не отвлекает от сути и быстро вводит в курс дела без лишних аккуратностей

Итоги 2025 года часть 1

Потихоньку решил писать итоги года и разделю это на несколько частей.

Этот год для меня является годом переездов.

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

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

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

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

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

Почему у них есть, а у нас нет?????

https://vc.ru/apple/2665260-apple-razreshit-storonnye-prilozheniya-i-platezhi-v-brazilii