Мобильная разработка

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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

Привет хабр! Есть проекты, которые начинаются не с бизнес‑плана, не с инвесторов и не с попытки «зайти в рынок». Они начинаются чуть проще — ты смотришь на существующие решения, пользуешься ими, раздражаешься и думаешь: «А почему это до сих пор выглядит именно так?»

Примерно так у меня появился ReDrive.

ReDrive — это open‑source мобильное OBD2-приложение, которое превращает смартфон в цифровую приборную панель и диагностический инструмент для автомобиля. Идея простая: подключаешь ELM327-совместимый адаптер к OBD2-порту машины, открываешь приложение и видишь данные с ECU в понятном виде: скорость, обороты, температуру, напряжение, состояние подключения, ошибки и другую телеметрию.

Недавно я дебажил проблему «Tinkoff Investments не открывается через VPN» — стандартная, split-routing проблема. Симптом: app запускается, картинки грузятся, но авторизационная сессия не поднимается, login висит. Через 30 минут возни со снапшотами /state, /connections, /logs и ручного matching'а conn_id'ов между ними картина прояснилась.

Часть доменов вида *.t-bank-app.ru корректно матчится в мой ru-domains rule_set и идёт напрямую. Но другая часть резолвится через CNAME на *.trbcdn.net (TLD .net!) — этот target в ru-domains уже не попадает, и sing-box честно отправляет трафик через bypass-VPN в Польшу. Получается split: часть запросов уходит с моего домашнего IP, часть — с польского. Bank-backend, который привязывает session к source-IP / fingerprint'у, видит непоследовательного клиента и просто отказывается поднимать auth state.

Симптом — «login завис», корень — domain-level split routing внутри одного приложения.

Стало ясно: такая диагностика не должна занимать 30 минут. Поэтому в L×Box (мой Android-клиент на sing-box, open source) появилась фича — Per-app traffic profiler.

На сайте Engee в разделе «Библиотека конечных автоматов» в наглядной форме представлены КА [1]. Полюбопытствуйте. Вполне достаточно для первого знакомства. Там есть раздел «Материалы Engee по Конечным автоматам», в который помещены проекты, демонстрирующие качества КА на практике. Сейчас это три проекта — «Регулирование температуры воздуха», «Электростеклоподъемник для автомобиля» и «Управление перекрестком». Подобно проекту браслета из первой части статьи [2] на их примере покажем возможности автоматного программирования (АП) в среде ВКПа в сравнении с автоматами Engee или, что будет точнее, в сравнении с моделью Харелла, реализованной здесь.

Выберем для этого проект с светофорами. На сайте имеется следующее его описание:

«Цель этого примера — разработать модель управления перекрестком, состоящим из двух автомобильных и одного пешеходного потоков, которые управляются двумя трёхсекционными и одним двухсекционным светофорами соответственно. Алгоритм переключения секций будет определяться согласно временной диаграмме. Управляющий алгоритм будет реализован при помощи нескольких блоков Chart, а снятие входных и формирование выходных сигналов — блоками C-Function.»

На рис. 1 показана структурная схема проекта в Engee. На ней несколько блоков, где основные — блок Commn_Counter, который моделирует временные такты диаграммы, блок Traffic_Lights, реализующий управление, заметим, сразу двумя светофорами и блок Crosswalk для светофора потока пешеходов. Временная диаграмма работы светофоров показана на рис. 2.

Привет, Хабр! Меня зовут Александр. В YADRO я разрабатываю приложения внутри оболочки kvadraOS: да, у нас есть своя оболочка на основе AOSP — в команде One UI, Color OS и MiUi прибыло. 

Сегодня расскажу о тайнах и тонкостях приложения «Системные настройки» — это наша реликвия, очень старое приложение с нагромождением костылей стилей и подходов. Когда наша команда взялась его перерабатывать, у нас было 230 000 строк legacy-кода на Java и около 300 активностей и фрагментов. Как вы понимаете, задача была не из легких.

Через что нам пришлось пройти, чтобы улучшить приложение, и почему мы не убежали не переписали его с нуля, расскажу дальше. Спойлер: было жестко, но все закончилось хорошо. Теперь у нас есть все основания утверждать, что работа над «внутренностями» Android — это высшая лига.

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

Статус 200 OK коварен своей тривиальностью.

Бэкенд-тесты «зеленые», API честно отдает данные, а веб-клиент мгновенно подхватывает изменения. Кажется, что всё в порядке, но в это же время мобильные клиенты теряют работоспособность. Приложение не выдает сетевых ошибок, оно просто не может корректно обработать обновленный DTO: клиент ожидает одну структуру данных, а получает другую.

Это не баг логики сервера, а технический разрыв между живым API и замороженным артефактом — версией приложения, которая ничего не знает о правках в схеме данных, сделанных через полгода после его релиза.

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

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

Я Алексей Матвеев, директор по мобильным технологиям в «Первой Форме», и в нашей компании, к сожалению, такое тоже происходит. Чтобы ловить такие расхождения до релиза, нам же был нужен прогноз совместимости до того, как изменения на бэкенде затронут пользователей. Мы создали прозрачный конвейер самодиагностики, который подсвечивает нестыковки в данных еще на этапе тестирования бэкенда, гарантируя корректную работу тех версий приложения, которые уже живут на устройствах пользователей. В статье расскажу подробно, как устроено это решение.

Разработка iOS-приложения для ручной съёмки на iPhone: ISO, выдержка, фокус, RAW, stop motion и попытка ограничить вычислительную обработку снимков. Описываю принцип работы приложения.

Миграция большого iOS-проекта с Objective-C на Swift кажется понятной задачей ровно до тех пор, пока не начинаешь считать объём. В нашем случае это были 10 тысяч файлов, сотни тысяч строк кода и постоянная необходимость не останавливать развитие продукта. Ручной подход работал слишком медленно, поэтому мы начали автоматизировать миграцию с помощью LLM — и в итоге превратили её из бесконечного техдолга в воспроизводимый процесс.

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

Меня зовут Андрей Сикерин, я руковожу одной из групп iOS-разработки Яндекс Браузера. Вместе со мной статью писала Елизавета Мазулова, разработчица из нашей же команды. Она создала систему промптов для миграции, ревью, рефакторинга и автоматизации тестирования. Вместе мы расскажем, как устроен весь процесс изнутри: от выбора порядка миграции модулей до контроля качества через тесты.

Все промпты, конфигурационные шаблоны и вспомогательные скрипты выложили в открытый доступ — забирайте и адаптируйте под свой проект. Мы уже проверили, что подход работает не только у нас: взяли открытый репозиторий приложения Wikipedia для iOS и без существенных изменений промптов мигрировали один из его пакетов и поделились результатом с сообществом в виде открытого PR.

Hola, Amigos! На связи Павел Гершевич, Mobile Team Lead агентства продуктовой разработки Amiga и соавтор книги «Основы Flutter». Иногда нужно реализовать поиск по данным без участия бэкенда. Самый простой вариант — обычное вхождение строки — не прощает опечаток. Одна лишняя буква, и поиск выдает пустоту.

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

Эта статья — про то, что реально изменилось, и в каком порядке я бы рекомендовал это
трогать. Основано на диффе между (3.3.0) и (8.6.2).

Почему SVG, который работает в Chrome, часто становится статичным или ломается во Flutter? Разбираю проблему animated SVG, SMIL, CSS keyframes, path morphing, фильтров и рассказываю, как из этой боли появился full_svg_flutter — SVG-рендерер для Flutter с более браузерным подходом к рендерингу.

Это статья от автора библиотеки, поэтому нейтральным разбор не будет. Но это и не рассказ про
конкретный проект — а разбор задач, на которых, на мой взгляд, Paging 3 начинает буксовать, и
того, как Paginator устроен, чтобы эти задачи
закрывать. KMP-библиотека пагинации для Android, iOS, JVM и Desktop. Ниже — почему она появилась
именно как отдельная библиотека, а не как fork или обёртка над Paging 3.

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

2-5 iOS разработчиков

Менеджер

Дизайнер

Тестировщик

Как видите, в списке нет DevOps, поэтому наш CI был полностью в нашем распоряжении и мы могли настраивать как нам удобно. Когда я присоединился к командам, то на CI уже всё было настроено по классике:

Mac Studio в подвале

Запуск Unit тестов

Запуск UI тестов

Сборки различных версий приложения (Firebase, TestFlight)

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

Время шло, задачи закрывались, релизы выпускались, в свободное время от задач расчищали беклог - в общем скукота. Так как мне нравится ковырять в носу xcodebuild через терминал, то иногда я стал замечать, что, например, тесты на CI и локально работают по-разному в плане скорости, локально вроде всё очень быстро, но на CI реально иногда надолго всё залипало - 5, 10, иногда 20 минут, хотя локально из консоли до двух раз быстрее.

После очередного закрытого спринта досрочно, осталось время на беклог, у меня закралась мысль, что что-то не так с нашим CI. Так как я знаю, что у нас на CI стоит Mac Studio, которая точно, хоть и немного, но шустрее моей машины, но по времени выполнения задач этого не скажешь.

Решил в итоге открыть ящик пондоры Fastfile и посмотреть, что же там и как это работает.

Назидательная статья, написанная в стихах и вдохновленная детскими книгами. Посвящается всем ошибкам, которые я совершал на работе — большим и маленьким.

За полгода я сделал мобильное приложение, получил 2000 установок и… 8 платных подписок по $6. Причем одна из подписок — моя.

Меня зовут Максим, я Android-разработчик в команде дизайн-системы «БКС Мир инвестиций». В 2025 году у нас шёл большой редизайн: компонентная библиотека росла, команды подключали новые Compose компоненты, а вместе с этим быстро рос и объём UI-тестов.

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

Эта статья про то, как мы решили задачу через Kotlin IR Compiler Plugin. Снаружи решение выглядит почти незаметно: разработчик ставит одну аннотацию, а на этапе компиляции компонент автоматически получает стабильный testTag и тестовые semantics, собранные из его state. В результате у команды стало меньше бойлерплейта в компонентах, меньше риска рассинхронизации между state и тестами, а экранные UI-тесты получили более устойчивый контракт работы с дизайн-системой.

Я разрабатываю PWA для голосовой практики английского. Несколько раз пытался опубликовать его в RuStore через Trusted Web Activity (TWA) — Google-обёртку, которая упаковывает PWA в подписанный Android AAB. После четырёх отказов модерации я понял, что для моего класса приложений TWA в RuStore не работает, и за день переключился на Telegram Mini App.

Эта статья — не история стартапа, а разбор технических решений:

Вообще‑то, я бэкендер последние лет 20, но недавно остался без работы (и AI тут не причём), решил «замутить» свой «стартап», пока ищу новую работу Java‑программиста. А заодно подтянуть новые технологии, поглубже изучить немецкий и английский и немного развеяться…

Писать приложения под iOS было моим хобби последние лет 10, и пару моих приложений до сих пор постоянно висят в топе в Российском AppStore, но это были всё «игрушки», а захотелось сделать что‑то взаправду стоящее, и так возникла идея написать лучшее (ни больше ни меньше) приложение для изучения языков с помощью аудирования. Точнее, товарищ подсказал идею. А ещё точнее — идея давно была реализована под Андроид, но аналогов под iOS нет, а очень хотелось. И мне, и товарищу:). Да и смартфона с андроидом у меня нет и никогда не было, не судите строго, но не люблю я вирусы и глюки.

Идея следующая: берёте любое аудио на любом нужном вам языке, загружаете в приложение, и оно автоматически (можно так же вручную) разбивает аудиофайл на нужные вам сегменты для «шэдоуинга», аудирования, многократного прослушивания и тому подобного. Аналогов в сторе я не нашёл, точнее, что‑то отдалённо похожее там есть, но без своих настроек, без выбора своего контента для изучения, без красивой визуализации аудио, короче, без всего того, что нам бы хотелось иметь.

Итак, идея есть, какие технологии использовать? В старых моих приложениях был UIKit, Realm/CoreData, и, сториборды. Не судите строго, я как бэкэндер тогда не знал, что использование сторибордов среди «трушных» айосников считается плохим тоном и плохой приметой. Но теперь‑то я решил использовать современные технологии! И выбрал такой стэк: SwiftUI, SwiftData, Speech Framework. Что касается последнего, то он вроде бы доступен ещё с iOS 10, но я решил, что технологии развиваются, и распознавание текста из аудио должно было бы сделать со времени iOS 10 огромный рывок вперёд. Но теперь я не так сильно в этом уверен, и об этом эта моя маленькая статья…

Рано или поздно каждый Android‑разработчик сталкивается с задачей «одно приложение — много сборок»: white‑label‑решения, региональные версии, отдельные сборки для разных магазинов приложений, демо для клиентов, внутренние окружения.

Встроенный механизм product flavors в Android Gradle Plugin отлично справляется со своей задачей — пока количество вариантов умещается в голове и в паре экранов build.gradle.kts.

В этой статье я разберу подход, при котором конфигурация flavors строится динамически: список вариантов и их параметры живут вне build.gradle.kts.