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

Мир меняется стремительно. ИИ занимает все более заметную роль. Все мировые гиганты, от Google до Microsoft, инвестируют миллиарды в развитие собственных AI-инструментов. Многие работодатели открыто признают силу ИИ и ищут сотрудников, которые уверенно им владеют.

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

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

В этой статье мы коснемся таких альтернатив классической разработке как zero-code (no-code), low-code и vibe coding. А также сравним, как к AI-инструментам, no-code/low-code-платформам относятся на зарубежных job-площадках и в российских компаниях.

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

В этом году на конференции Google I/O 2026 команды Flutter и Dart отмечают важную тему: «Везде, каждый день, создано всеми, для всех».

Dart 3.12 воплощает эту идею в жизнь. Мы делаем язык более доступным и продуктивным. Лаконичные новые примитивы, такие как приватные именованные параметры, наряду с экспериментальной поддержкой основных конструкторов, делают повседневное программирование более чистым. Но мы не остановились на синтаксическом уровне. Новые функции, такие как Agentic Hot Reload и добавление Genkit в экосистему Dart, гарантируют, что вы сможете создавать высокопроизводительные, готовые к использованию ИИ и агентные приложения, которые будут доступны пользователям в любой точке мира. Это справедливо как для индивидуального программирования, так и для парного программирования с ИИ-агентом.

Так что вперед flutter upgrade, следуйте инструкциям, чтобы изучить новые возможности Dart 3.12. Но помните, что более мощный Dart — это только половина дела. Когда вы будете готовы увидеть, как эти функции преобразуются в красивый пользовательский интерфейс, ознакомьтесь с публикацией в блоге «Что нового во Flutter» или на Хабре.

Google I/O 2026.

Flutter 3.44 уже здесь, и это грандиозное событие! Этот релиз знаменует собой важную веху в истории Flutter: Hybrid Composition++ для Android, Swift Package Manager в качестве нового менеджера пакетов по умолчанию для iOS/macOS и улучшенную поддержку Vulkan для Impeller. Мы представляем предварительную версию поддержки многооконного режима для настольных компьютеров, и Canonical станет нашим новым ведущим разработчиком, а также начинаем масштабную архитектурную эволюцию, отделяя Material и Cupertino от основного фреймворка. Мы переосмысливаем UX для агентного взаимодействия с пользователями с помощью GenUl и переосмысливаем опыт разработчиков с помощью Agentic Hot Reload и Dart & Flutter Agent Skills. Flutter расширяет возможности приложений следующего поколения — повсюду, от мультимедийной системы Toyota RAV4 2026 года до грядущего SDK для webOS от LG. Мы очень рады поделиться с вами всеми новостями и обновлениями; добро пожаловать в Flutter 3.44!

Однажды у нас появилась задача, которая (на первый взгляд) выглядела очень простой: сделать опросник в приложении. На макетах всего лишь пара экранов, несколько вопросов, кнопка «Далее». Всё красиво, не сухо, с картинками у вариантов ответа и нормальной подачей, а не в формате «Заполните обязательные поля»

Судя по макету всё просто: сверстать флоу и отправить все ответы одним POST в конце. Самый короткий путь — зашить вопросы, переходы и тексты на клиенте. Делов на пару дней — сделал и забыл. 

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

Каждая правка текста, картинки, порядка вопросов или маршрута снова уезжает в релизный цикл web, iOS и Android. А синхронизировать такие изменения между тремя платформами намного сложнее, чем кажется на старте.

По некоторым косвенным признакам мы понимали, что с этой анкетой всё будет именно так, поэтому в качестве альтернативы мы выбрали путь backend-driven UI, когда клиент показывает поддерживаемые типы экранов, а backend управляет сценарием: текстами, изображениями, порядком шагов, переходами и состоянием прохождения.

Ниже расскажу почему мы пошли в backend-driven подход, где он действительно помог, а где показал явные ограничения и мог выбить нас из сроков.

Итак, погрузимся в прошлое, помянем конец октября 2023 года.

При обновлении Flutter до версии 3.13.8 после запуска flutter doctor я получил неожиданное предупреждение:

Меня зовут Родион, и я уже около 2,5 лет работаю в VK Android-разработчиком в крупном многомодульном проекте с сотнями экранов и довольно большой аудиторией. Когда я попал на проект, стек был классическим и проверенным: XML-вёрстка, навигация через Cicerone, Dagger 2 для DI, Coroutines и Flow для асинхронщины, а в качестве архитектурного паттерна — MVVM. 

Рано или поздно любая растущая кодовая база упирается в потолок своих архитектурных решений. У нас этот момент настал, когда количество экранов выросло до нескольких сотен и команда начала тратить больше времени на борьбу с неконсистентным состоянием UI. Классическая связка XML + ViewBinding + MVVM работала, но с каждым новым экраном мы всё острее чувствовали её ограничения: разрозненные StateFlow, дублирование кода во фрагментах, сложность переиспользования компонентов. 

Нужно было что-то менять — пересмотреть сам подход к построению UI. Так мы начали миграцию на Jetpack Compose (который на момент начала перехода уже был стабильным и самодостаточным). Полтора года спустя, пройдя через рефакторинг базовых классов, переход с MVVM на MVI и постепенную замену содержимого всех фрагментов, мы получили стек, на котором разработка ускорилась, а баги, связанные с состоянием экрана, практически исчезли. 

Полный переход на Jetpack Compose мы разделили на три больших этапа:

- переписываем содержимое всех фрагментов на ComposeView;

- переходим с Dagger2 на Koin;

- меняем навигацию с Cicerone на Compose-навигацию.

О втором и третьем этапах кратко расскажу ниже —  в главе стратегии перехода, а на первом этапе остановлюсь подробнее.

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

Экосистема Flutter совершила один из самых значительных скачков вперед. С выходом Flutter 3.44 команда официально сделала Swift Package Manager (SwiftPM) менеджером зависимостей по умолчанию для iOS и macOS, ознаменовав начало конца эпохи CocoaPods.

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

Telegram — технически самый сложных мессенджер в мире. В iOS приложении 2.1M+ строк, 700+ модулей, 86% Swift, 13 лет кодовой базы, и мало ObjC — это колоссальный труд.

Но при этом приложение лагает на флагманах, AsyncDisplayKit открывает по 10 дублей окон разом(а это явно тормозит ARC), крэши на редактировании изображений стабильны годами.

Почему?

Потому что 86% кода написаны на Swift, но разработчики мыслят все еще в парадигме ООП.

ООП в Swift — это не просто устаревший стиль, это потерянная производительность.

Хабр, привет! Меня зовут Борис Денисенко. Я мобильный разработчик и наставник на курсе «Android-разработчик» в Яндекс Практикуме. У себя в блоге я пишу про Android Automotive OS, но сегодня отойду от частностей и расскажу, в каких ещё сферах может работать мобильный разработчик, если он не занимается приложениями для смартфонов и планшетов.

Я декомпилировал APK мессенджера MAX и проверил его поведение по коду. нашёл: скрытый SDK деанонимизации с отправкой реального IP в обход VPN на сторонний домен, недокументированную запись аудио со звонков по команде сервера, отключённую проверку TLS‑сертификатов в QUIC‑канале медиа, серверный C2-канал через WebSocket с командами выгрузки контактов и логов, аппаратный фингерпринт через Widevine DRM, ZipSlip в загрузчике моделей, передачу номера телефона по открытому HTTP, силовое обновление в обход Google Play, управление NFC‑payload из мини‑приложений, трекинг адресной книги в реальном времени и ещё несколько находок. Все находки сверены с реальным кодом, ссылки на файлы и классы в zarazaex69/m

Возвращаемся после небольшого майского перерыва с новым дайджестом - советы и хитрости Xcode 16 и как добиться 0 рекомпозиций в сложном кастомном UI, три раунда войны с Android-клавиатурой в WebView и обновление без разрешения пользователя, 10 оптимизаций Swift, которые улучшат производительность, тестирование Compose по-новому, декларативная навигация для Flutter, под капотом перезапуска приложения Бургер Кинг и многое другое. Заходите!

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет.

Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync(). Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё.

В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

Как банки превратили «выгоду» в головоломку: семь карт, куча кешбэков — и один способ из этого выбраться.

Плагин для JetBrains-IDE, который встраивает полноценный Telegram прямо в редактор. Плюс шифрованный шеринг кода, подсветка синтаксиса в теме получателя и магия с метаданными в обычном тексте сообщения. Разбираю изнутри.

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

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

Что будем делать или что может быть интересного в статье:

- Пайплайн из двух независимых LLM агентов

- Запуск и анализ ошибки UI автотеста (Root Cause Analysis)

- Фикс автотеста в цикле с его запуском.

- Кастомизация MCP инструментов чтобы оптимизировать контекстное окно.

- Система приоритетов в работе LLM агентов.

Сотня рекомпозиций в секунду при скролле — это приговор. Приговор батарее устройства, плавности анимаций и вашей репутации как инженера. Мы привыкли мыслить высокоуровневыми абстракциями: закинуть LazyColumn, добавить пару Modifier.padding и отправить в продакшен. Но что делать, когда стандартные компоненты начинают "захлебываться", а Layout Inspector горит красным от избыточных отрисовок?

Если ваше мобильное приложение общается с бэкендом, значит, скорее всего, живёт по контракту в виде OpenAPI-схемы. Смотреть на неё удобнее всего в Swagger, а все изменения в API можно отслеживать вручную.

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

Привет! Меня зовут Дима Максимов, я Android-разработчик в Дринкит. Этой статьёй я открываю цикл, в котором мы разберёмся, как настроить генерацию из Swagger в Kotlin-код и как обуздать автогенерацию в условиях многомодульного проекта.

Нет, это не déjà vu, это продолжение моей прошлой статьи Самый быстрый XML парсер для iOS в 2026 году? Чтобы вам не тратить время на ее чтение, вот краткий пересказ. В прошлой статье происходит поиск самого быстрого XML парсера со следующими характиристиками:

Для Apple платформы (iOS, tvOS, macOS)

Язык Objective-C или Swift

GitHub как источник исходников

Популярный (хотя бы больше 500 звезд)

Любая интеграция (CocoaPods, SwiftPM)

И самое важное, весь бенчмарк я писал сам с небольшой помощью ИИ, не спеша, под несколько чашечек кофе за 3 часа я нашел нужный мне XML парсер.

Спустя пару месяцев после выхода первой статьи, мне пришла мысль, зачем я тратил 3 часа на эту задачу, если можно было просто это самое задание “скормить” ИИшке и она бы за 5 минут решила бы ее (так пишут в интернетах). Тут же пришла вторая идея. Так как у меня есть мною лично проверенный результат, то я могу загрузить этой задачей все популярные ИИ и их результаты сравнить со своим. Даже не исключаю, что у меня где-то есть ошибка и тогда рейтинг парсеров будет выглядеть совсем иначе и я выбрал не самый быстрый как хотел.

Собственно, что я и сделал. Загнал задачу в топ 15 ИИ и сравнил их результаты со своим. Если вам интересно, кто справился с задачей, кто спасовал, будет описано в развернутой статье под катом.

Для затравки, наихудший результат и последнее место занимает GPT 5.5 Pro. А Claude Opus 4.7 не смог взять первое место.