Одно приложение для курьеров на iOS и Android: плюсы и минусы кроссплатформы

У большинства курьерских служб парк смартфонов пёстрый: штатные курьеры ходят с выданными Android-устройствами, самозанятые — со своими телефонами, а среди них заметная доля айфонов. Делать два отдельных приложения под iOS и Android — значит платить двум командам, синхронизировать два релиза и разбираться, почему на одной платформе статус «Вручено» работает, а на другой нет. Отсюда популярный вопрос: можно ли обойтись одним кроссплатформенным приложением и что при этом потерять.

Короткий ответ: для типового приложения курьера — маршрут, список заказов, статусы, фото, подпись, оплата — кроссплатформа обычно экономит 30–40% бюджета и заметно упрощает поддержку. Но у неё есть узкие места: фоновая геолокация, работа со сканерами ТСД, офлайн-режим и поведение на дешёвых смартфонах. Эти вещи нужно проверить до старта, а не после релиза. Если собственной мобильной команды нет, разумно обсудить задачу с подрядчиком, который делает и кроссплатформенные, и нативные приложения, — например, с YUSMP Group: так проще получить честное сравнение двух подходов под ваш парк, а не продажу одного из них.

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

Что такое кроссплатформенное приложение курьера

Кроссплатформенное приложение — это одна кодовая база, из которой собираются версии для iOS и Android. Бизнес-логика (заказы, статусы, расчёт оплаты, синхронизация с TMS) и чаще всего интерфейс пишутся один раз. Нативные возможности телефона — GPS, камера, Bluetooth, push-уведомления — подключаются через плагины или небольшие платформенные модули.

Для сравнения, есть ещё три подхода:

• Нативная разработка — два отдельных приложения на Swift (iOS) и Kotlin (Android). Максимум контроля и производительности, но двойная стоимость и две команды.
• PWA (веб-приложение) — открывается в браузере, ставится на рабочий стол. Дёшево, но фоновая геолокация, работа без связи и доступ к сканеру ограничены, особенно на iPhone.
• Гибридные приложения на WebView (Cordova, Ionic) — по сути сайт в оболочке. Для курьеров сегодня выбирают редко: на слабых телефонах интерфейс тормозит.

Для курьерской службы реальный выбор почти всегда между нативом и одним из «настоящих» кроссплатформенных фреймворков: Flutter, React Native или Kotlin Multiplatform.

Почему службы доставки выбирают одну кодовую базу

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

• Бюджет. Одна команда вместо двух. По типичным оценкам подрядчиков, экономия на разработке — 30–40%, на поддержке обычно больше, потому что каждое изменение делается один раз.
• Одинаковое поведение. Логика статусов и расчёта выплат одна на обе платформы. Не бывает ситуации, когда на Android новая причина отказа уже есть, а на iOS — только в следующем релизе.
• Скорость изменений. Тарифы, правила приёмки, новые маркетплейсы-партнёры меняются часто. В кроссплатформенном проекте правка выходит на весь парк одновременно.
• Найм и подрядчики. Flutter- и React Native-разработчиков на рынке достаточно, проект проще передать другой команде.
• Самозанятые на своих телефонах. Если курьеры приходят со своими устройствами, поддерживать обе платформы обязательно, и делать это дешевле одной кодовой базой.

Курьеру всё равно, на чём написано приложение. Ему важно, чтобы кнопка «Вручено» срабатывала с первого раза — и одинаково на любом телефоне.

Где кроссплатформа упирается в ограничения

Слабые места кроссплатформы для курьеров известны заранее, и почти все они связаны с работой «под капотом» телефона, а не с интерфейсом.

Ни один из этих рисков не делает кроссплатформу непригодной. Каждый из них просто означает, что в проекте будет 10–20% нативного кода, и это нужно заложить в бюджет и сроки сразу, а не обнаружить в середине разработки. Подробнее о работе со сканерами мы писали в материале про Android-терминалы сбора данных на складе.

Flutter, React Native или Kotlin Multiplatform: что выбрать

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

Практическое правило выглядит так. Если вы начинаете с нуля и у вас много бюджетных Android-устройств — чаще выбирают Flutter: интерфейс рисуется собственным движком и одинаково выглядит на любом телефоне. Если у компании уже есть веб-кабинет клиента или диспетчерская на React, React Native позволит переиспользовать часть логики и людей. Если работающее Android-приложение уже есть и нужно быстро добавить iOS для самозанятых, Kotlin Multiplatform даёт вынести общую логику, не переписывая всё. Перед выбором полезно пролистать официальную документацию — Flutter, React Native и Kotlin Multiplatform: в каждой есть раздел о работе с нативными модулями, от которого зависит судьба фонового GPS и сканеров.

Какие функции курьера нужно проверить до старта

Прежде чем подписывать оценку, попросите подрядчика сделать технический прототип — 2–3 недели работы, который проверяет самые рискованные функции на ваших устройствах. Минимальный список:

1. Фоновый трекинг 8–10 часов. Приложение свёрнуто, экран выключен, курьер переключается на навигатор и мессенджер. Трек должен быть непрерывным, а расход батареи — не больше 15–20% за смену.
2. Офлайн-сценарий. Отметить три заказа «Вручено» с фото в подвале без связи, выйти на улицу — все статусы и фото должны уйти без дублей и в правильном порядке.
3. Сканирование. Штрихкод и QR камерой на iPhone и бюджетном Android при плохом освещении; на ТСД — встроенным сканером.
4. Push-уведомления. Новый заказ или изменение маршрута приходят на обе платформы, в том числе на Android-смартфоны с агрессивным энергосбережением. Отдельно проверьте устройства без сервисов Google — их доля в парках заметна.
5. Фото и подпись. Съёмка, сжатие и отправка без зависаний на телефоне с 3 ГБ памяти.
6. Интеграция с вашей системой. Получение заказов и отправка статусов через API вашей TMS для курьерской службы или учётной системы.

Если прототип проходит эти шесть проверок, остальная часть приложения — экраны, справочники, профиль, выплаты — для кроссплатформы рутина. Если нет — вы узнаёте об этом за 2–3 недели, а не за 4 месяца.

Сколько стоит и сколько времени занимает

Точная цена зависит от объёма функций и интеграций, но соотношение подходов на типовом приложении курьера стабильное. Ориентиры ниже — для MVP с маршрутом, статусами, фото, подписью, push-уведомлениями, офлайн-режимом и интеграцией с одной учётной системой.

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

Когда лучше остаться на нативной разработке

Кроссплатформа — не универсальный ответ. Нативные приложения разумнее, если:

• Парк — только корпоративные ТСД на Android. iOS не нужен, а значит, нет и экономии от общей кодовой базы. Нативное Android-приложение даст полный доступ к SDK сканера.
• Все водители на iPhone с корпоративными устройствами. Тогда достаточно одного нативного iOS-приложения — подробности в нашем разборе приложения для водителей на iOS.
• Тяжёлая работа с «железом»: весы, принтеры этикеток, телематика авто, NFC-метки на каждой точке. Чем больше устройств, тем больше нативных мостов, и экономия тает.
• Уже есть зрелое нативное приложение. Переписывать работающий продукт ради смены технологии почти никогда не окупается. Разумнее развивать то, что есть, или выносить общую логику постепенно.

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

Как запустить проект без лишних рисков

1. Соберите факты о парке. Сколько курьеров на iOS и Android, какие модели, версии ОС, есть ли ТСД и устройства без сервисов Google. Без этой выгрузки выбор технологии — гадание.
2. Опишите смену, а не экраны. Шаги от приёмки до сдачи кассы, пять самых частых действий, условия без связи. Принципы удобного интерфейса мы собрали в статье про UX приложения для курьеров.
3. Закажите технический прототип с шестью проверками из раздела выше — на ваших реальных устройствах.
4. Зафиксируйте долю нативного кода в оценке: какие модули, кто их поддерживает, что будет при обновлении ОС.
5. Пилот на одной зоне. 10–20 курьеров на 2–4 недели, сравнение с текущими показателями: доля статусов «на месте», звонки диспетчеру, разрывы трека.
6. Раскатка и поддержка. Единый релизный цикл, мониторинг падений по обеим платформам, канал обратной связи из приложения.

Если технологическую часть вы ведёте сами, а операции — найм, обучение и управление курьерами — удобнее передать на сторону, посмотрите, как это устроено в решениях MetroMax BPM.

Частые вопросы о кроссплатформенном приложении курьера

Подходит ли кроссплатформа для приложения курьера?

Да, для большинства служб доставки со смешанным парком iOS и Android это рациональный выбор: одна кодовая база, синхронные релизы и экономия 30–40% бюджета. Важно заранее заложить нативные модули для фонового GPS, сканеров ТСД и эквайринга.

Что выбрать для курьеров — Flutter или React Native?

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

Будет ли кроссплатформенное приложение тормозить на дешёвых телефонах?

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

Можно ли работать со сканером ТСД из кроссплатформенного приложения?

Да, через небольшой нативный модуль-обёртку над SDK производителя терминала. На iPhone и обычных Android-смартфонах в это время используется сканирование камерой — логика приложения остаётся общей.

Сколько времени занимает разработка кроссплатформенного приложения курьера?

MVP с маршрутом, статусами, фото, подписью, push-уведомлениями, офлайн-режимом и одной интеграцией обычно занимает 3–4 месяца против 4–6 месяцев для двух нативных приложений. Технический прототип рискованных функций — 2–3 недели.

Стоит ли переписывать готовое нативное приложение на кроссплатформу?

Как правило, нет: переписывание работающего продукта редко окупается. Если нужно добавить вторую платформу, рассмотрите Kotlin Multiplatform — он позволяет вынести общую логику из существующего Android-приложения постепенно.