Кроссплатформенное приложение для бизнеса: когда подходит
Когда общий код для iOS и Android уместен, какие функции проверить заранее и почему кроссплатформенность не отменяет отдельное тестирование.
Кроссплатформенное приложение подходит бизнесу, когда пользователям iOS и Android нужен в основном одинаковый продукт: каталог, личный кабинет, запись или работа с заказами. Часть интерфейса и логики можно разрабатывать совместно. Но общий код не означает одинаковую трудоёмкость для любых функций и не отменяет проверки на каждой платформе.
Решение стоит принимать по сценариям, а не по обещанию «два приложения по цене одного». Важнее выяснить, какие действия выполняет клиент, какие устройства использует и какие внешние системы уже работают в компании. Ниже — способ подготовить эти вводные до обсуждения технологии.
1. Сначала сравните сценарии двух платформ
Запишите путь пользователя от входа до результата. Например: открыть каталог, выбрать товар, оформить заказ, увидеть его состояние. Если этот путь одинаков для обеих аудиторий, у проекта есть понятная общая часть. Различия в отдельных кнопках или оформлении ещё не означают, что нужны два независимых продукта.
Отдельно перечислите данные: товары, клиенты, заказы, адреса, история действий. Уточните, откуда они приходят и кто вправе их менять. Приложение не должно создавать параллельный каталог только потому, что у него новый интерфейс. Связь с существующим сайтом и учётной системой нужно оценивать вместе с экранами.
Проверьте и саму потребность в установке. Если человеку нужен разовый расчёт или редкое обращение, сначала полезно сравнить приложение с удобным мобильным сайтом. Повторный сценарий — аргумент в пользу приложения, но не доказательство спроса. Его лучше подтвердить разговорами с будущими пользователями и наблюдением за текущей работой.
2. Найдите функции, которым нужен технический прототип
Для предварительной оценки разделите требования на обычные действия продукта и функции с неопределённостью. Во вторую группу могут попасть связь со специальным оборудованием, сложная обработка видео, нестандартная работа в фоне или интеграция с закрытой системой поставщика. Это повод проверить реализацию, а не автоматически отказаться от общего кода.
В React Native предусмотрен платформенный код: отдельные части приложения могут отличаться для iOS и Android. Для возможностей, которых нет в готовых средствах проекта, можно подключать нативные модули. Такая возможность не делает интеграцию бесплатной: её совместимость, поддержку и объём разработки нужно изучить отдельно.
Хороший прототип отвечает на конкретный вопрос: «Получаем ли мы данные с нужной модели устройства в согласованных условиях?» Демонстрация красивого экрана этого не подтверждает. Заранее определите оборудование, версии систем, ограничения доступа и признак успешной проверки. Результат прототипа должен влиять на смету и выбор подхода.
Если рискованная функция составляет основу продукта, проверьте её до детальной отрисовки всех экранов. Иначе можно согласовать удобный интерфейс вокруг возможности, которая на целевых устройствах работает иначе, чем ожидалось. Нужные доступы и тестовые устройства лучше подготовить со стороны заказчика заранее.
3. Оцените не только написание экранов
В бюджете остаются серверная часть, интеграции, тестирование, подготовка выпусков и дальнейшие обновления. Общий код может уменьшить дублирование, но нельзя заранее обещать определённый процент экономии. Сравнивать стоит две оценки одного и того же состава работ, включая поддержку после запуска.
Попросите показать границы ответственности: кто готовит доступы к сервисам, наполняет каталог, проверяет расчёт стоимости и принимает результат. Если приложение зависит от внешнего API, уточните, кто исправляет ошибку на его стороне. Без этого обсуждение технологии скрывает организационные риски вместо того, чтобы их снять.
Для приёмки составьте общие сценарии и выполните их отдельно на согласованных устройствах. Проверьте вход, потерю соединения, повторное нажатие, ошибки данных и возврат после прерывания. Один успешный показ на телефоне разработчика не заменяет такую проверку. Также определите, кто получает сообщения о сбоях после выпуска.
4. Подготовьте короткий документ для выбора
Достаточно одной страницы: аудитория, основной сценарий, нужные платформы, существующие системы, необычные функции и критерии приёмки. Отметьте, что обязательно в первом выпуске, а что можно отложить. Добавьте ограничения бюджета и желаемую дату, чтобы обсуждать реалистичные варианты состава работ.
На странице разработки приложений можно посмотреть мой подход к проекту. В кейсе SplitCash показан собственный выпущенный продукт; это пример реализации, а не обещание одинакового результата для другого бизнеса.
Если вводные пока неполные, начните с описания действий пользователя. Я помогу выделить общую часть и вопросы для проверки. После этого можно выбирать подход и оценивать работу без предположения, что название технологии само по себе решит ограничения проекта.