Разработка мобильных приложений *

Привет, Хабр! На связи снова Максим из ATI.SU.

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

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

Этой статьёй мы открываем цикл о UI‑тестировании iOS приложений. Начнём с основ: разберёмся, какое место UI‑тесты занимают в пирамиде тестирования, познакомимся с инструментами и постепенно перейдём к построению устойчивых тестов с применением проверенных паттернов.

Серия: redb ecosystem (инженерный разбор после анонса 3.2.1)

Когда вышел SQLite-провайдер 3.2.1, анонс был на пару абзацев: «тот же LINQ, одна строка в DI». Эта статья — противоположность анонса. Здесь не «что вышло», а как оно устроено и где у нас потекло. Конкретно: как движок запросов redb переехал в нативное C-расширение там, где у базы нет хранимок; как мы храним DateTimeOffset в базе, у которой нет типа «дата»; и три бага из этого релиза, разобранные с фильтр-JSON, сгенерированным SQL и фиксом.

Это длинно и с кодом. Если хочется коротко — читайте анонс по ссылке выше. Если интересно, что под капотом «одной строки в DI», — устраивайтесь.

Привет, Хабр! На связи Дмитрий Андриянов, iOS-разработчик команды Медиа Платформы в Т-Банке. Одна из наших ключевых задач — разработка видеоплеера для стриминговых видео, в том числе для приложения T-Инвестиций, где есть лента тематических роликов и обучающие видео в Академии.

В T-Инвестициях на iOS лента коротких роликов — это 90% трафика, именно ее оптимизации мы уделяем больше всего внимания. В первой версии пользователи могли ждать старта видео больше 15 секунд. Мы разобрались в ограничениях AVPlayer, оптимизировали буферизацию и снизили задержки на 12% в хвосте распределения. Рассказываю, как мы улучшали пользовательский опыт и почему AVPlayer не лучшее решение для ленты роликов.

Здравствуйте. Надеюсь, тут есть люди, которые интересуются вайбкодингом (хотя в списке тем рассылки такой не нашёл, что для меня странно), и уж точно есть те, кто занимается разработкой мобильных приложений. Да, сегодня эти слова очень часто встречаются рядом, что неудивительно. Я большую часть жизни проектировал фронтенд для b2b веб-приложений, но руки всегда чесались в сторону мобильной разработки, случай никак не подворачивался. А тут, как из рога изобилия, посыпались различные ИИ, которые способны после пары абзацев произвольного текста буквально за 5 минут сделать готовое мобильное приложение. Да, я не устоял и попробовал. И доложу я вам, это так. Приложение работает! Но, как говорится, есть нюанс: оно не сильно похоже на то, что вы себе представляли. А уж мне, как дизайнеру, было вообще грустно. Эту грусть я пока не победил, но победил кое-что другое, и это не про дизайн.

Думаю, многие из нас успели заметить стремительное изменение рынка в последние пару лет: он плавно превратился из рынка соискателя в рынок нанимателя и, пожалуй, стал наиболее конкурентным и жёстким за всё время существования IT в России.

К тому же, старая проблема поиска работы тоже никуда не делась: умение писать классные Android-приложения не всегда гарантирует успешный найм. То, что спрашивают на интервью, и задачи, которые мы решаем каждый день, совпадают далеко не всегда.

Поэтому навык прохождения собеседований становится всё важнее. В этой небольшой статье хотел бы разобрать 10 популярных вопросов, с которыми можно столкнуться на собеседованиях по Android в 2026, поехали 🚀

В этом выпуске хардкорная агентская разработка под iOS и Preview-Driven скриншот тестирование для Android, кольца-расстояния и инерция пальца, пять ошибок начинающих Android‑разработчиков и пять ошибок при работе с Jetpack Compose, динамические иконки приложения на Flutter, ручной DI в Kotlin Multiplatform, расширенные возможности оплаты и низкие комиссии в Google Play, и многое другое. Заходите!

Агентская разработка развивается семимильными шагами. Но не всё идёт так радужно, как хотелось бы. Например, ИИ-агенты по умолчанию заваливают разработчика вопросами: а можно я сделаю вот так? а если скриптик написать? а можно я на гитхаб схожу? а можно я соседний проект гляну?

Это приводит к consent fatigue — я не раз ловил себя на мысли, что я уже давно только и делаю, что жму “allow”, “allow everytime”, редко вникая в суть того, что спрашивает агент, но полностью доверить агенту делать всё, что ему заблагорассудится, мне как-то боязно. Всё-таки на основном макбуке много личных и рабочих данных, которые агент может случайно (или через prompt injection) удалить или слить в сеть. Стрёмно. Поэтому я какое-то время играл в игру “я типа читаю, что ты у меня спрашиваешь”.

Хотя правильное решение — запуск агента в режиме YOLO (в случае claude — с флагом --dangerously-skip-permissions). И тогда при правильной постановке задачи агент может часами сам работать и делать то, что нужно, уведомляя меня только по выполнении.

Это первая статья цикла. Здесь — базовая настройка Mac Mini и вся возня с SSH, чтобы YOLO-агент работал на отдельной машине без ручного ввода паролей и переживал разрывы сети. Специфику iOS-разработки (git worktree, параллельное тестирование, idb, прогон приложения, грабли симулятора и прочее) я вынес в следующие части, так что статья будет полезна не только iOS-разработчикам, но и всем, кто хочет запускать YOLO-агентов и не париться о безопасности. С некоторыми оговорками, разумеется, подробности ниже.

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

Граф зависимостей KMP‑приложения можно собрать обычным Kotlin‑кодом — без рефлексии, кодогенерации, аннотаций и DSL. Composition root и конструкторы, никакой магии. Звучит как шаг назад от зрелых DI‑фреймворков — пока не посмотришь, кому такая форма удобна: тебе, новому человеку в команде и твоему ИИ‑агенту.

Hola, Amigos! На связи Павел Гершевич, Mobile Team Lead агентства продуктовой разработки Amiga. Мы с командой подготовили для вас перевод статьи о том, как можно кастомизировать иконку приложения динамически. Всем приятного чтения!

Два месяца назад я опубликовал статью про свой pet-проект — E2EE-мессенджер.

Честно говоря, я не ожидал, что она вызовет такой интерес. Прилетели комментарии, замечания, вопросы и довольно полезная критика. Где-то меня поправили по делу. Где-то заставили пересмотреть решения, которые мне самому на тот момент казались нормальными.

И, что самое приятное, часть вещей, которые тогда были только в roadmap, за это время удалось реализовать.

Первая часть:

https://habr.com/ru/articles/1030854/

Проект:

https://github.com/vaazhen/chaos-e2ee-messenger

Вообще, за эти два месяца я понял одну простую вещь.

Написать чат оказалось не так сложно.

Написать E2EE-мессенджер — уже сложнее.

А вот понять, почему Signal делали столько лет, оказалось совсем другой историей.

Сначала кажется: ну есть же документация, есть X3DH, есть Double Ratchet, есть WebCrypto, есть статьи, есть спецификации. Осталось просто аккуратно всё собрать.

Примерно в этот момент где-то вдалеке начинает смеяться инженер из Signal.

Сразу оговорюсь: chaos messenger — это не замена Signal и не “готовый безопасный мессенджер”, а open-source pet-проект, на котором я разбираюсь, как E2EE-системы устроены изнутри.

Я больше 10 лет занимался мобильной и системной разработкой, и сейчас меня догнал тот самый кризис 30-ти. В какой-то момент стало понятно: в IT я когда-то пришёл не только ради задач, релизов и багов, а потому что хотел делать игры. Так и началась Petri Dish Lab — мобильная игра про бактерий, вирусы, генетику и маленькую лабораторию в кармане.

Тестирование мобильных устройств на производстве — это процесс, где цена ошибки очень высока. Баг в приложении можно исправить в обновлении, а дефект аппаратной части планшета или смартфона обычно обнаруживается после сборки устройства, а иногда — только у конечного пользователя, и устранить его намного сложнее. Поэтому важно находить дефекты на всех этапах производства: от поверхностного монтажа до сборки готового планшета.  

Привет, Хабр! Меня зовут Сергей, я ведущий инженер программист в отделе разработки приложений в YADRO. В статье расскажу, как мы создавали систему производственного тестирования Android-планшетов, которая используется на этапах сборки и в отделе технического контроля.

Если после релиза Android‑приложения вы внезапно получаете краши, утечки памяти и жалобы на пропадающие данные, проблема может скрываться в нескольких строках кода вокруг Activity и Fragment.

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

Я сделал анти-шагомер на Expo и React Native: приложение, которое награждает за неподвижность и ругает за шаги. Снаружи это шутка про anti-wellness, внутри — Android step counter, background tasks, локальные пуши, Zustand, native-модуль для TYPE_STEP_COUNTER и state machine для чек-апа “я живой, но мне лень”. Рассказываю, что сломалось по дороге и почему фоновая логика в мобильной разработке — это не cron.

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

Привет, Хабр! 

Я Дмитрий, iOS-разработчик из команды Салют — мы делаем устройства и программное обеспечение для Умного дома Сбер. У нас много собственных устройств и ещё больше устройств брендов-партнёров, которые поддерживает платформа. Релизный круговорот фичей и интеграций заставляет думать: как оптимизировать процесс доставки новых функций пользователям?

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

ИИ-ассистент с долговременной памятью, агентами и vision. Память с весами и забыванием, разные модели под задачу, поиск по маркетплейсам с инъекцией профиля. Проблемы с 152-ФЗ: данные уезжают за рубеж, а GigaChat не может.

В новом дайджесте вопросы доступного пространства в условиях ненадежного поведения horizontalSizeClass и выход Android 17, гид в смешанной реальности с использованием Android XR и живой космос на Metal, иерархия корутин в Android, приложение с расписанием автобусов, скам сети с подписками, домашний сервер с Qwen Code за 25к и многое другое. Подключайтесь!

Разбор того, как отказаться от системного UINavigationBar и собрать собственный навигационный бар на обычном UIView: с коллапсирующим large title как у Apple, встроенной строкой поиска и произвольными панелями под заголовком — и так, чтобы он работал и с UITableView, и со списками на Texture (AsyncDisplayKit). Внутри — устройство компонента и честный разбор компромиссов из реального продакшена.