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

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

Всем привет! Меня зовут Милена, я бэкенд‑инженер на Java в Банки.ру. Полтора года назад я вызвалась написать мобильное приложение для команды, в которой не было ни одного мобильного разработчика. За три месяца мы его выпустили, оно работало на обеих платформах, и я закрыла для себя вопрос, ради которого во все это ввязалась «понравится ли мне мобильная разработка» — спойлер: ответ оказался «нет».

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

Привет!

Представьте, что вы с удовольствием пишите один код на все платформы на Kotlin Multiplatform, и вдруг приходит задача «синкать данные раз в час, только по вайфаю и когда телефон на зарядке».

Под Android вы берёте WorkManager и за пятнадцать минут закрываете тикет. Потом яблочный смежник открывает документацию по BGTaskScheduler и обнаруживает, что модель там вообще другая и работает всё по-другому: нет очереди задач, есть окна, которые система выдаёт по своему усмотрению и т. д.

В итоге в проекте появляется expect fun scheduleSync() с разными реализациями, которые ведут себя по-разному, и никто в команде через год не сможет сказать, что именно произойдёт на iOS, если приложение свернули посреди загрузки.

Так как я андроидер с альтернативным мышлением, мне нравится API WorkManager'а. Я захотел его скопировать под KMP, породив так называемый Kotlin Multiplatform Work Manager или же Jabbit (job + rabbit, да, я знаю) — планировщик фоновых задач для KMP.

Таргеты: Android, iOS, js и wasmJs. Как будет время и желание, появится ещё и декстоп.

Привет, Хабр! Я Евгений Шувагин, последний год работаю над компонентом Face-Shot в Т-Банке.

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

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

И вот я не давно опять вернулся к пересказам. Но теперь уже не в школе и с тетрадкой, а в метро и с телефоном. Пользоваться гуглом транслейтом оказалось не так уж и удобно и я подумал а почему бы самому не сделать специализированное приложение с подстветкой нужной строки, с текстом на русском и английском и самое главное синхронной прокруткой двух окон на разных языках. Так и родился приложение «Удобный пересказ».

В новом выпуске 136 уровней вложенности XCUITest и Android Runtime под капотом, как Tinder сократил холодные старты на 47% и новые условия распространения приложений в Евросоюзе, от Event-Driven UI к State-Driven UI, что нового в Dart, как сделать MCP удобными и действительно полезными, уменьшение трения в приложениях и многое другое. Заходите!

Я работаю в офисе (вспоминается песня "Ленинграда") и моим основным рабочим инструментом уже очень долгое время является Excel. Рискую показаться предвзятым, но на мой взгляд Excel - это лучший продукт Microsoft. И вообще электронные таблицы, как класс приложений, - это абсолютно гениальное изобретение человечества. Наверное многие считают из злом, но давайте пройдемся по фактам:

Человек уже решил записать еду. Но вместо ввода приложение предлагает поиск, штрихкод, фото, AI, рецепт, избранное — и ещё несколько дверей. Я сравнил девять трекеров и проверил на моём обеде, где появляется лишнее состояние.

Наверное, у каждого такое было: приходишь на работу, а под дверями твоего кабинета уже стоит хмурый работяга — начальник участка и взволнованная девушка менеджер. «Он должен был сдать отчёт и не сдал, у меня сырья не хватает — детали в базе не собираются» — говорит она. «Я что, мальчик какой‑то — по десять раз бумажки переписывать, я все вчера ей на стол положил» — ворчит он. «Да он постоянно забывает и ошибается ещё»... «Да она всегда все теряет, и переписать с бумажки не может». Полчаса взаимных упрёков и испорченное на весь день настроение. Я хочу рассказать, как помирить производство и офис внедрением простого микросервиса.

Привет, Хабр! Меня зовут Женя, я занимаюсь развитием цифровых продуктов в Sminex. В статье поделюсь опытом разработки и запуска Sminex Event — собственного продукта для управления корпоративами.

Всем привет! Меня зовут Егор Савинцев, я Frontend Platform Engineer в Авито. Сейчас я работаю в команде архитектуры, а до этого в команде Phobos в рамках Платформизации переводил страницу объявления на Beduin — разрабатывал клиентскую архитектуру и переписывал блоки. 

Сразу важное отступление. 

Beduin — это Backend‑Driven UI. Если в нативе в коде клиентского приложения есть компоненты, бэкенд присылает им данные, и всё работает. В Beduin бэкенд присылает и данные, и сами компоненты в специальном виде. На клиенте у нас только рендерер — специальный компонент, который принимает JSON и рендерит то, что мы прислали. 

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

Статья будет полезна frontend‑ и mobile‑разработчикам, инженерам платформенных команд, архитекторам клиентских приложений и backend‑разработчикам, которые внедряют Backend‑Driven UI. В общем, всем, кто планирует переводить крупные экраны на BDUI и хочет заранее узнать, что может пойти не так. Спойлер: всё.

На экране идет диалог: 

— Она мне уже неделю не отвечает

— Это редфлаг. Не пиши ей больше

— Но я не хочу ее потерять!

А на фоне кто-то играет в Minecraft, GTA или другую игру. 

Не спрашивайте, в чем тут юмор. Просто так уж повелось.

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

Чтобы открыть Twitter, не нужно нажимать «Начать читать твиты». А чтобы выучить несколько слов, почему‑то нужно начинать целую тренировку. Я решил сломать систему и полностью выпилить этот этап, где нужно принимать решение о начале занятия.

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

Меня зовут Шуст Иван, за мной закреплено более 15 продуктовых команд, что делают фичи ежедневного входа, профиля, истории операций и связанные с безопасностью. Поэтому я, как лид, имею прямое отношение к процессам внедрения accessibility в Альфе, проживший последний год, пытаясь наладить и внедрить процессы accessibility, расскажу о всех граблях, которые мы собрали. Вы узнаете о рабочих подходах при работе с доступностью и как делать вот точно-точно не надо. 

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

React Native по-прежнему часто описывают формулой «один код для iOS и Android». В 2026 году она звучит слишком просто. Современное приложение на React Native — это общий продуктовый слой на TypeScript, нативный интерфейс, Hermes, Fabric, JSI, фоновые процессы, platform-specific код и довольно много решений о том, где именно должна выполняться каждая задача.

Мы столкнулись с этим в Synchra.24 — мобильном приложении для линейных и распределённых команд. В проекте больше тысячи TS/TSX-файлов и свыше ста экранов, но рядом с ними живут Kotlin и Swift: геопозиция, push-уведомления, биометрия, системные виджеты и работа с медиа. Это не история о функциях нашего продукта и не попытка его рекламировать. Это разбор того, чем на практике стала разработка на React Native к 2026 году — и какую часть этой работы действительно можно поручить нейросетям.

В октябре прошлого года на Хабре вышла статья «Как я писал свою звонилку для видеозвонков» — автор под ником CEOCTO за несколько вечеров написал P2P-видеозвонилку на WebRTC, потому что его достали обрывающиеся созвоны в мессенджерах. Я прочитал, улыбнулся, полез смотреть исходники на GitHub — и на этом всё. Как обычно бывает с чужими pet-проектами: оценил, закрыл вкладку, забыл

Привет! Меня зовут Даниил, я iOS-инженер в Циане. В этой статье расскажу, как мы заставили XCUITest работать с экраном, к которому он в принципе не мог подойти.

У нас есть server-driven UI экран, наш BDUI, про движок которого была отдельная статья. Дерево вьюх у него настолько глубокое, что любое обращение теста к элементам падало. Причём двумя разными способами, и оба — не из-за кода, а из-за жёстких лимитов внутри самого фреймворка автоматизации.

В итоге мы научились читать дерево произвольной глубины и тапать/вводить текст в поля, которые лежат глубже ~60 уровней AX-дерева, где публичный XCUITest бессилен. Далее я буду фокусироваться на общей технике для XCUITest, а не на внутреннем устройстве нашего движка. Так что статья пригодится, даже если у вас никакого BDUI нет, а просто есть очень глубокий экран.

Мы рады объявить о выходе Dart 3.13!

В этом релизе мы отмечаем тему, которую любят все разработчики: чистый и легковесный код. Dart 3.13 фокусируется на этом аспекте на каждом уровне работы разработчика. Что касается языка, то первичные конструкторы устраняют повторяющийся шаблонный код, позволяя определять классы в одной строке кода. В инструментах разработчика внесены улучшения, позволяющие dart formatподдерживать аккуратность кода в соответствии с правилами стиля Effective Dart , а также dart pubвведены новые команды рабочей области для поддержания порядка в монорепозиториях. На pub.dev расширенные функции документации, такие как <callout-box>теги и {@example}директивы, делают документацию пакетов более понятной. Внутри системы, оптимизация кода нативных библиотек (tree-shaking @RecordUse) и отложенная загрузка WebAssembly помогают сделать скомпилированные бинарные файлы приложений максимально компактными.

Так что обновите Dart или запустите программу flutter upgrade и следите за обновлениями, пока мы будем изучать новинки Dart 3.13!

В этом дайджесте Android-приложение Polymarket на Swift, Structured Concurrency и отмена корутин, что нового во Flutter 3.47 и разработка мобильного приложения с помощью Claude Code, конкурирующие магазины приложений в Play Store, ИИ, парализовавший принятие решений и многое другое. Заходите!

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