Android на Python для enterprise: где выигрывает, где подводит

Android-разработка на Python (Kivy, BeeWare, Chaquopy) ускоряет прототип и позволяет переиспользовать существующий Python-код бизнес-логики, но для enterprise-приложений с интеграцией 1С, сканерами и публикацией в сторах чаще выигрывает гибридная связка — нативный Kotlin-каркас с Python-модулями через Chaquopy или прямая разработка на Kotlin либо Flutter.

три способа писать Android на Python — и что каждый на самом деле даёт

Термин «Android на Python» скрывает три разных технологии, и путать их — стандартная ошибка на старте. Kivy — фреймворк с собственным UI-движком поверх SDL2: интерфейс рисуется самим Kivy, а не системными компонентами Android, поэтому кнопки и поля выглядят одинаково на любой версии ОС, но не как Material Design. Для enterprise это не эстетическая деталь: часть корпоративных заказчиков проверяет мобильные приложения через MDM-политики и требует соответствия гайдлайнам платформы, а нестандартный рендер интерфейса иногда всплывает именно на этапе приёмки, а не на демо для пользователей. BeeWare, точнее его UI-слой Toga, идёт другим путём — превращает Python-код в вызовы нативных Android-виджетов, экран выглядит по-андроидовски, но сама экосистема заметно младше и беднее готовыми компонентами. Chaquopy — не самостоятельный UI-фреймворк, а Gradle-плагин, который встраивает интерпретатор CPython внутрь обычного нативного Android-проекта на Kotlin или Java. Экран и работа с оборудованием остаются нативными, а Python подключают точечно — для конкретного модуля: расчёта, парсинга, обращения к API 1С.

Для enterprise это разделение принципиально. Первые два варианта дают Android-приложение, написанное на Python целиком. Третий даёт нативное приложение, где часть логики написана на Python — и это два разных проекта с разной ценой владения.

сравнение с Kotlin и Flutter — цифры, а не ощущения

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

где Python реально экономит бюджет

Годится Python не как замена нативной разработке, а как способ не переписывать то, что уже работает. Частый случай в нашей практике: у компании уже есть Python-скрипт, который считает скидки, маршруты доставки или скоринг клиента — он гоняется на сервере рядом с 1С и годами накапливал бизнес-правила. Переписать это на Kotlin — отдельный проект на несколько недель, риск разойтись с оригиналом в деталях. Через Chaquopy этот же код подключается к нативному Android-приложению почти без изменений: экран и работа со сканером остаются на Kotlin, а расчёт — тот же файл, что крутится на сервере.

Вторая ситуация — внутренний инструмент для 10-30 сотрудников, который никогда не попадёт в Google Play: сверка остатков на складе, форма для полевого аудита, прототип для демонстрации инвестору. Здесь минусы Kivy — тяжёлый APK, не самый быстрый отклик интерфейса — не критичны, а скорость сборки на знакомом стеке важнее. Если в штате уже есть Python-разработчик, который писал интеграции с 1С, тестовую версию такого инструмента он соберёт за несколько дней, не дожидаясь найма мобильного разработчика. Третья ситуация — пилот перед крупным контрактом: компании нужно за две-три недели показать инвестору или заказчику работающий макет с реальными данными из 1С, чтобы получить бюджет на полноценную разработку. Здесь скорость сборки важнее эстетики интерфейса, а после защиты пилота проект осознанно переписывают на нативный стек — и закладывают это в план с самого начала, а не как аварийную меру.

риск для enterprise, который не виден на демо: поддержка и рынок труда

Демо на защите проекта показывает готовый экран. Оно не показывает, что произойдёт через полтора года, когда Google поднимет обязательный target SDK и приложению нужно обновление просто чтобы остаться в Google Play, а специалист по Kivy, который его писал, уже работает в другой компании. Рынок труда здесь асимметричен: Android-разработчиков, свободно владеющих Kotlin, на порядок больше, чем тех, кто предметно поддерживал продакшн-приложения на Kivy или BeeWare — большинство Python-разработчиков писали backend или анализ данных, а не мобильный UI. Найти замену на нативный стек — вопрос недель, найти замену на Kivy-проект корпоративного масштаба — вопрос месяцев, и цена такого найма обычно выше рыночной именно из-за редкости навыка.

Отдельно стоит вопрос фоновой работы приложения: push-уведомления о новых заявках, синхронизация в фоне при плохой связи на складе, поведение при разрыве соединения с 1С. У Kivy и BeeWare эти механизмы работают поверх нестандартных для Android процессов и требуют больше ручной настройки, чем у нативного приложения, где WorkManager и стандартные системные сервисы решают задачу из коробки. Для enterprise-приложения, которое должно работать предсказуемо у сотен пользователей одновременно, а не только у команды тестировщиков, это не мелочь, а часть контракта на поддержку.

подольский склад: во что обошлась ставка на чистый Python

Логистическая компания под Подольском заказывала мобильное приложение для комплектовщиков: сканировать штрихкод, списывать остаток, синхронизировать данные с 1С:Управление торговлей. Условие заказчика было одно — работать с уже закупленными терминалами сбора данных Zebra TC21, менять оборудование никто не планировал. Разработчик со стороны подрядчика выбрал Kivy: в команде был Python-программист, а срок до демо — три недели.

Демо на эмуляторе прошло гладко: экран сканирования, синхронизация, всё по плану. Но на реальном терминале сканер не заработал через штатный интерфейс Kivy — SDK Zebra рассчитан на нативный Android-слой, а мост из Python к нему заранее никто не проверял. Поэтому три недели превратились в переписывание модуля сканирования на Kotlin и последующую склейку его с Python-частью через JNI — по сути, второй проект поверх первого. Демо для склада перенесли на пять недель позже исходного срока, а бюджет разработки вырос, по нашей оценке типичных случаев такого рода, примерно на треть — платить пришлось и за Python-часть, и за нативный мост, который изначально в смету не закладывали.

Ставка в такой ошибке — не абстрактная потеря времени, а конкретный простой склада: комплектовщики две лишние недели считали остатки на бумаге, а логист вручную сверял их с 1С по вечерам.

как мы собираем такие приложения в ukved

В ukved мы делаем заказную разработку мобильных приложений для бизнеса, и стек выбираем не по принципу «на чём умеет писать разработчик», а по тому, какое оборудование и какая интеграция стоят в требованиях. Если в проекте есть сканер, NFC-метки или касса — экран и работа с железом идут на нативном Kotlin, а Python через Chaquopy подключаем только туда, где заказчик готов и хочет переиспользовать уже существующую бизнес-логику.

Если ядро задачи — обмен данными с учётной системой: остатки, цены, статусы заказов, заявки — мы делаем интеграцию приложения с 1С через OData или HTTP-сервисы независимо от того, на каком стеке собран клиент. Для складских и полевых сценариев чаще всего собираем B2B-приложение с 1С целиком на нативном стеке — там, где нужна предсказуемая работа с оборудованием годами, экономия на Python-обёртке не окупает риск.

Отдельный случай — когда приложению вообще не нужна кастомная логика, только мобильный интерфейс к данным 1С. Тогда быстрее и дешевле не писать клиент с нуля ни на Python, ни на Kotlin, а собрать его на 1С:Мобильной платформе прямо из конфигурации.

Стоимость разработки мобильного приложения с нуля у нас начинается от 500 000 рублей — итог зависит от того, сколько логики переносится из готового Python-кода и сколько потребуется нативных модулей под оборудование. Актуальные цены и тарифы — на отдельной странице. На старте проекта мы отдельно оцениваем, есть ли у заказчика готовый Python-код, который стоит перенести через Chaquopy, — это снижает итоговую стоимость по сравнению с разработкой той же логики с нуля на Kotlin.

чек-лист: 5 вопросов, чтобы не ошибиться со стеком

• ✓Приложение будет работать с внешним оборудованием — сканером, NFC, кассовым принтером? Если да, UI и работа с железом должны быть нативными, Python — только для отдельного модуля через Chaquopy.
• ✓Есть готовый Python-код, который уже проверен в проде — расчёты, скоринг, парсинг? Тогда Chaquopy экономит недели переписывания, а не наоборот.
• ✓Приложение выйдет во внешний Google Play или RuStore для клиентов компании? Тяжёлый APK и нестандартный интерфейс Kivy здесь заметны пользователю с первого запуска.
• ✓Заказчик — госструктура или компания с обязательным импортозамещением? Тогда в перспективе может понадобиться включение в реестр российского ПО — требования касаются прав на код и юрлица-правообладателя, а не языка программирования.
• ✓Задача — мобильный интерфейс к 1С без сложной логики? Быстрее не выбирать между Python и Kotlin вообще, а собрать приложение на 1С:Мобильной платформе.

❓ Частые вопросы

Можно ли использовать готовый Python-код (например, расчёт скидок) в enterprise-приложении на Android без переписывания на Kotlin?

Да, через Chaquopy — Gradle-плагин встраивает интерпретатор Python в нативный Android-проект. Экран и работа с оборудованием остаются на Kotlin, а существующий Python-модуль подключается почти без изменений и продолжает считать так же, как на сервере.

Подходит ли Kivy для приложения, которое увидят обычные клиенты компании в Google Play?

Технически да, но интерфейс Kivy рисуется собственным движком и не повторяет Material Design, а APK тяжелее нативного. Для внутреннего инструмента это не проблема, для витрины бренда во внешнем сторе — заметный минус.

Сколько стоит превратить существующий Python-прототип в полноценное enterprise-приложение?

Разработка мобильного приложения с нуля у нас начинается от 500 000 рублей. Итоговая цена зависит от объёма логики, которую можно перенести из готового Python-кода через Chaquopy, и от количества нативных модулей под оборудование.

Что выбрать, если приложению нужен просто мобильный интерфейс к 1С без сложной логики?

В этом случае быстрее и дешевле не выбирать между Python и Kotlin вообще, а собрать клиент на 1С:Мобильной платформе прямо из конфигурации 1С — без отдельной кодовой базы под Android.

Как в Python-приложении работать с ТСД-сканерами и другим оборудованием склада?

Напрямую через Kivy или BeeWare SDK производителей часто не подключаются. Рабочий вариант — нативный модуль на Kotlin для работы с железом, а Python через Chaquopy оставить только для расчётной логики.