или заполните форму
разработка
Пять трендов мобильной разработки 2026
Максим Жуков
Сооснователь ecommerce-агентства KISLOROD
В 2026 году мобильное приложение можно дорабатывать с ИИ-агентом, а часть запросов покупателя — обрабатывать на телефоне. Разберем, что изменилось в инструментах разработки и требованиях платформ и как это использовать в приложении интернет-магазина.
1. Поиск с LLM
Разработчикам стало проще добавить в приложение локальную языковую модель. В июне 2025 года Apple представила Foundation Models framework — доступ к модели Apple Intelligence на устройстве. У Google для подобных задач есть ML Kit GenAI на базе Gemini Nano. Эти инструменты поддерживают обработку текста без отправки каждого запроса в облако. Набор функций зависит от платформы и конкретного API.
Для магазина один из вариантов применения — поиск по описанию задачи. «Нужна тихая посудомойка для маленькой кухни» — покупатель может сформулировать пожелание, даже если не знает, какие фильтры выбрать. Модель помогает разобрать запрос. Дальше начинается работа с каталогом: в нем должны быть размеры и уровень шума, по которым можно подобрать технику. «Маленькая кухня» не задает ширину ниши в сантиметрах; ее нужно уточнить у покупателя.
Цену, наличие и условия доставки приложение получает из систем магазина. Если модель предлагает собрать корзину, наличие товара и скидку проверяет сервер. В документации Gemini такой обмен описан через вызов функций: модель выбирает действие и передает параметры, а выполняет его код приложения. Итоговую сумму и состав заказа подтверждает покупатель.
Локальная обработка запроса не делает весь этот сценарий доступным без интернета. Она может помочь понять пожелание, но актуальные остатки все равно нужно запросить у магазина. Есть и ограничения самого устройства: модель может не поддерживать нужный язык или вовсе быть недоступна на телефоне. Для таких случаев в приложении сохраняют обычный поиск либо используют серверную обработку.
Прежде чем расширять функцию на весь каталог, ее можно проверить в одной товарной категории. Сравнить с обычным поиском: удается ли найти подходящий товар, переходят ли покупатели к оформлению заказа. В расходы включить подготовку характеристик, проверку ответов и поддержку на разных устройствах. При облачной обработке добавляется стоимость запросов. Отсутствие платы за каждый локальный вызов не отменяет остальной работы.
2. ИИ-агенты в разработке
В Agent Mode в Android Studio разработчик описывает задачу, а агент составляет план, меняет несколько файлов и проверяет результат доступными ему средствами. Можно поручить ему подготовить тесты, разобраться в незнакомом участке проекта или внести согласованное изменение. Это уже работа с задачей целиком, хотя предложенные правки еще нужно принять и проверить.
Для заказчика здесь возникает вопрос о сроках. Если разработчик быстрее получил код, это пока не означает, что раньше готов релиз. Время может уйти на ревью, исправление неудачных решений и проверку интеграций. Сравнивать нужно сопоставимые задачи от постановки до готовности к выпуску, включая переделки.
В отчете DORA за 2025 год ИИ описан как усилитель уже существующих особенностей команды: отдача от инструментов зависит от организации работы. Для мобильного проекта это повод проверить собственный процесс. Например, если изменения ждут ревью по несколько дней, более быстрая генерация кода сама по себе эту задержку не устранит.
В пилоте можно взять повторяющийся тип задач — доработки карточки товара или формы заказа. Зафиксировать затраченное время, замечания на ревью и ошибки после выпуска. По этим данным команда сможет оценить, где агент действительно сокращает работу и как изменится стоимость следующих задач. Заранее обещать одинаковую экономию на любом проекте оснований нет.
3. Внедрение общего кода для iOS и Android
В мае 2025 года Compose Multiplatform для iOS получил стабильный статус. С его помощью команды на Kotlin могут писать общий код интерфейса для iOS и Android. Объем общей части разработчики выбирают сами: в Kotlin Multiplatform можно объединить работу с данными, сохранив отдельные интерфейсы для каждой платформы. Во Flutter для постепенного внедрения есть add-to-app — способ встроить модуль в уже работающее приложение.
Магазин может начать с одного раздела: сделать общую программу лояльности или объединить код, который обрабатывает корзину в приложениях. На этой задаче команда проверит, сколько работы удается выполнить один раз для обеих платформ и где все еще нужны отдельные решения.
До выбора технологии нужно проверить сложные интеграции. Для магазина это могут быть оплата с переходом в банковское приложение или карта пунктов выдачи. Их включают в технический прототип: экран со списком товаров мало скажет о том, как приложение будет работать с внешними сервисами.
При оценке перехода учитывают обучение команды и перенос кода, а после запуска — поддержку библиотек и интеграций. Эти расходы сравнивают со стоимостью доработок на нынешнем стеке. Иногда выгоднее продолжать развивать два отдельных приложения. Для нового общего модуля тоже нужна своя оценка: даже небольшой раздел нужно связать с остальным приложением и проверить на обеих платформах.
4. Новые правила для больших экранов
В Android 16 приложение может занять все окно планшета или складного устройства, даже если разработчики ограничили его пропорции, ориентацию и изменение размера. По умолчанию это правило действует для приложений с целевым API 36 на экранах с наименьшей шириной от 600 dp. Есть исключения: для API 36 разработчик еще может временно сохранить прежнее поведение.
Интерфейс магазина нужно проверить в таких условиях. Узкая колонка карточек на планшете может оставить полэкрана пустым. Если просто растянуть ее, фотографии займут слишком много места, а выбирать товары удобнее не станет.
Если покупатели часто заходят с больших экранов, свободное место можно использовать по-другому: расположить фильтры рядом с каталогом, а детали заказа — рядом со списком заказов. Тогда покупателю не нужно постоянно переходить между экранами. Какие разделы так переделывать, зависит от того, чем он пользуется: повторяет прошлую покупку или собирает большой заказ из B2B-каталога.
При тестировании проверяют и сохранность введенных данных. Покупатель повернул планшет или изменил размер окна — адрес и выбранный пункт выдачи должны остаться на месте. Речь не об адаптивной верстке: сохранение данных разработчики настраивают отдельно. Также нужно проверить, можно ли оформить заказ с увеличенным шрифтом, экранным диктором или внешней клавиатурой.
5. Витрина без новой версии приложения
К распродаже магазину может понадобиться другая витрина, например, подборка товаров наверху, условия акции рядом с ней, отдельный блок для участников программы лояльности. Если расположение элементов задано в коде приложения, такие изменения потребуют релиза. После публикации еще нужно дождаться, пока покупатели установят обновление.
При Server-Driven UI разработчики заранее добавляют в приложение набор компонентов, а сервер передает, какие из них показать и в каком порядке. Приложение собирает экран по этому описанию. Так работает, например, открытый фреймворк DivKit. Из готовых компонентов команда может собирать разные варианты витрины без выпуска новой версии приложения.
Для самостоятельной работы маркетологам нужна панель управления, где можно настроить экран и проверить его перед публикацией. Разработчики также проверяют, как изменения отображаются в старых версиях приложения и что увидит покупатель, если описание экрана не загрузится. Если нужного компонента в приложении еще нет, его сначала добавляют с обновлением.
Для замены фотографии или текста хватает уже настроенной связи с CMS. Серверное управление интерфейсом имеет смысл рассматривать, когда команда регулярно меняет состав экранов и ожидание релизов задерживает запуск акций. Перед внедрением можно разобрать последние кампании: какие изменения потребовали разработчика и сколько времени прошло от согласования витрины до ее появления у покупателей. По этим данным проще оценить, окупится ли отдельная система управления экранами.
Что проверить перед обновлением
Если вы хотите обновить приложение и добавить новые функции, до обсуждения сроков и бюджета разберите с командой, что потребуется для каждой доработки. В таблице собрали вопросы для такой оценки и проверки результата:
В оценке проекта полезно разделить разовую разработку и регулярные расходы: проверку ответов модели, обновление интеграций, поддержку старых версий. Тогда станет видно, сколько будет стоить функция после первого релиза.
Если для такой оценки нужно разобраться в текущем приложении, в KISLOROD можно начать с аудита и предпроектной проработки, а после выбрать состав работ и подход к разработке.
Часто задаваемые вопросы
Нужен ли ИИ-поиск маленькому интернет-магазину?
Смысл покупать технологию, если в каталоге сотни и больше товаров с разными характеристиками, а покупатели формулируют запрос своими словами, а не терминами из фильтров. Для узкого ассортимента обычный поиск с фильтрами часто справляется не хуже и обходится дешевле во внедрении и поддержке.
Что выбрать — Kotlin Multiplatform или Flutter?
Зависит от того, что уже есть в проекте. Kotlin Multiplatform подходит, если хотите объединить только часть кода — например, работу с данными и бизнес-логику, — сохранив нативный интерфейс на каждой платформе. Flutter дает больше готового общего кода и интерфейса «из коробки», но менее гибок там, где нужна плотная интеграция с возможностями конкретной платформы. Ответ на этот вопрос дает не сам факт выбора инструмента, а прототип со сложной интеграцией — например, оплатой, — который стоит собрать до финального решения.
Обязательно ли переходить на Server-Driven UI?
Нет. Если изменения в витрине сводятся к замене фотографий, текста и цен, для этого обычно достаточно уже настроенной связи с CMS. Server-Driven UI оправдан, когда команда регулярно меняет состав и расположение экранов — например, под акции, — и релизный цикл заметно задерживает такие запуски.
Нужно ли адаптировать приложение под большие экраны, если у магазина мало покупателей с планшетов?
Начиная с Android 16 и целевого API 36 приложение может растянуться на весь экран планшета или складного устройства независимо от того, ограничивали ли это разработчики. Даже при небольшой доле такого трафика стоит хотя бы проверить, не съезжает ли верстка и не остается ли часть экрана пустой — доработка витрины под большие экраны нужна не всегда, а вот проверка базовой работоспособности критична всегда.
Получайте полезный контент от KISLOROD в любом из мессенджеров
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.
Рекомендованные статьи
Скачайте 17 точек роста и 100 + чекеров для роста конверсии и прибыли интернет-магазина
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.
Мы проанализировали ведущие интернет-магазины, результаты исследований, свой опыт и собрали важные моменты в одно руководство. Делаем e-commerce лучше, поэтому не только пользуемся сами, но и делимся с вами.
Выберите удобный мессенджер и получите чек-лист прямо сейчас:
