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

Привет, Хабр! Я разрабатываю open-source мессенджер Xipher (C++/Android), и одна из фич, которую пришлось проектировать особенно тщательно — Panic Mode. Это система правдоподобной отрицаемости (plausible deniability): при вводе специального PIN-кода мессенджер показывает полностью фейковую, но убедительную базу данных с поддельными чатами, а параллельно отправляет скрытый SOS-сигнал на сервер.

В статье разберу архитектуру целиком — от криптографического разделения баз до генерации правдоподобных фейков и маскировки panic-алерта под рутинный сетевой запрос. Весь код — из реального проекта.

Исходники открыты — ссылка на GitHub в конце статьи.

Мы привыкли думать, что интернет — это что-то невесомое. Но за каждой загрузкой страницы стоит сервер, а он расходует электричество. Умножаем на миллиарды просмотров в день — и вот у веба уже вполне осязаемый углеродный след. Хорошая новость: мы, как разработчики и дизайнеры, можем его уменьшить. Давайте разберёмся, как.

Эта статья - перевод поста в блоге Alex, Baton Corporation Team Lead, вышедшего 20 февраля 2026 г.

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

В этом выпуске бесконечная история сторибордов и расцвет «достаточно хорошей» архитектуры в Android, Baseline Profiles и шейдеры, мягкая обводка текста, мобильный геймдев нулевых и многое другое. Заходите!

Мне 18 лет, и последние несколько месяцев я разрабатываю Xipher — мессенджер, который пишу с нуля на C++ (бэкенд) и Kotlin (Android). В какой-то момент я захотел добавить фичу, которой нет ни в одном популярном мессенджере: режим, в котором переписку невозможно подделать — ни участникам, ни мне как владельцу сервера, — и это можно проверить независимо, без доступа к серверу.

Так появился Xipher Provable Chat. В этой статье разберу, как именно это реализовано, какие решения я принял и с какими проблемами столкнулся.

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

По умолчанию OpenClaw управляет локальным браузером. Для пары простых сценариев это ок. Но как только начинается что-то серьёзнее — параллельные сессии, большие флоу — машина становится узким местом. RAM улетает, всё начинает тормозить, прогоны становятся нестабильными. Плюс вы фактически запускаете агента рядом со своим реальным браузером — с куками, сессиями и всем остальным. С точки зрения безопасности это спорное решение.

Firecrawl выкатили решение — Browser S andbox. И это уже инфраструктурный подход, а не «девтул».

История, как я докатился до измерения скорости iOS xml парсеров в 2026 году.

Имеется один пет проект, где на старте приложения происходит скачивание большого xml файла на 500 тыс. строк (вес файла 65 Мб) и потом парсинг, на результате которого строится UI приложения. Так как я не люблю тянуть зависимости без лишней необходимости, то написал простой парсер на базе Foundation.XMLParser в паре с его делегатом XMLParserDelegate. Результат мне выдал 15 секунд ожидания на старте приложения, именно столько времени требовалось чтобы парсить пару String и пару Date типов полей. Думал на тот момент 500К строк и 15 секунд, наверное, пойдет для пет проекта, быстрее наврятли сделать, потому что визуально по коду парсер уже не улучшить, так как сделал кеширование ключ-значение и еще микро-хаки. И так прошло 3 года, приложением пользуюсь каждый день, уже привык к 15 секундам на старте, всегда думал, можно улучшить только поиском более быстрого xml парсера, но было лень для каждого парсера изучать API и руками писать бенчмарк, так и оставил до лучших времен.

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

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

Почему мобильное приложение — это база

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

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

Как мы работали раньше и почему ушли от готовых решений

Раньше мы работали с личным кабинетом на SharePoint и нативным мобильным приложением. Оно выполняло базовые задачи, но со временем стало очевидно: архитектура достигла предела масштабируемости, производительность просела, а развивать функционал стало сложно. Требуемую доступность 24/7 оно не обеспечивало.

Представьте ситуацию: у вашего продукта 50+ стейкхолдеров (30 бизнес-заказчиков, 5 архитекторов и еще 20 связанных систем)  и все одновременно чего-то хотят.

Есть «очевидное» решение: нанимать больше людей. Но это порочная практика. Сколько бы людей вы ни наняли, если нет фильтра на входе, задач всегда будет больше, чем ресурсов.

Меня зовут Денис Тучин, я отвечаю за процессы разработки мобильного приложения ВкусВилл в IT-компании ТехВилл. В этой статье я расскажу, как мы прошли путь: квоты → RICE → ROI, с какими проблемами столкнулись на каждом этапе и какие выводы сделали.

Flutter & GitLab CI/CD. Доставка мобильного приложения в Significa, TestFlight и Google Play

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. После успешной настройки сборки и подписания Flutter-приложений во второй части, остался последний, но не менее важный этап — дистрибуция приложения.

В современных условиях автоматизация деплоя на такие платформы, как Google Play, TestFlight и Significa, становится необходимостью. В этой статье мы разберем, как с помощью GitLab CI/CD настроить автоматическую отправку ваших приложений в магазины, чтобы вы могли сосредоточиться на разработке, а не на рутинных задачах.

Всем привет, меня зовут Двенадцатова Таня. Я руководитель команды исследователей в «БКС Мир инвестиций». Почти 2 года назад у нас в БКС появились Прожарки. Это мероприятие придумала не я. Более того, его концепция и идея мне изначально не нравились и не были на 100% понятны. Встреча называлась дерзко «Поясни за UX», и явка для всей команды исследователей на нее была строго обязательной.

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

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

В этой, уже 3 по счету статье мы переходим к самому важному месту во всей архитектуре Capacitor — к плагинам.

Именно плагины делают из WebView полноценное мобильное приложение. С ними у Вас появляется доступ к камере, файловой системе, push-уведомлениям, Bluetooth и т.д.

В статье разберем:

как устанавливаются официальные плагины;

как работать с community-плагинами;

как мигрировать с Cordova;

и главное — как написать собственный плагин с нуля на реальном примере отправки SMS.

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

Давайте же разберем как делать переходы в iOS-приложениях так, чтобы они не раздражали, не ломали флоу и не заставляли пользователя думать "что-то пошло не так". Выясним почему 60 FPS - это не всегда гладко, как избежать типичных багов вроде джанка и мигания, правильно использовать matchedGeometryEffect, писать кастомные переходы без костылей и отлаживать всё это дело до идеального состояния. В конце разберём реальный кейс - переход от списка к детальной странице без единого моргания экрана.

Всем привет! Меня зовут Влад Шатиленко, я продакт-менеджер в команде технической платформы Авито. Раньше я был разработчиком: начинал с аутсорса, затем работал в стартапе, где со временем перешёл в продакты. Сейчас в Авито занимаюсь развитием инструментов backend-driven UI — о них и пойдёт речь дальше. Статья будет полезна командам, которым важны скорость экспериментов, быстрые изменения интерфейса и кроссплатформенность.

Android-приложение может быть написано аккуратно и архитектурно выверено, но это не гарантирует быстрый запуск и стабильную работу в проде. Значительная часть задержек рождается на уровне ART: загрузка классов, интерпретация dex-кода, JIT-компиляция «горячих» методов и постоянный сброс прогрева после обновлений.

В статье разберём, как Baseline Profiles позволяют управлять install-time оптимизациями, что именно они меняют в жизненном цикле приложения и почему в реальных кейсах это даёт измеримый прирост производительности.

В новом дайджесте происходит что-то серьезное: наложенные окна и 37 000 unit-тестов против Gradle, новый Flutter и эксперимент с эмоциональным банкингом, Developer Knowledge API от Google, опасности в Android, подводные камни миграции на Swift и многое другое. Заходите!

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

Swift 6 вводит более строгие проверки изоляции конкурентности и поддерживает поэтапную миграцию, модуль за модулем. Хотя рекомендуемая Apple стратегия выглядит мягкой, на практике вы можете столкнуться со скрытыми сбоями во время выполнения, особенно когда в проекте одновременно сосуществуют модули на Swift 5 и Swift 6.

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

Вы узнаете, как на самом деле работает магия приложения Локатор (Find My в англоязычной версии): от аппаратных хитростей контроллера питания до пост-квантовых алгоритмов шифрования. Мы разберем, почему «выключенный» iPhone - это лишь иллюзия для пользователя, как математика защищает ваши координаты от самой Apple и почему ваш смартфон превращается в криптографический маяк, когда гаснет экран. Статья будет интересна разработчикам, специалистам по безопасности и всем, кто хочет понимать реальные возможности (и ограничения) современной электроники.