Сравнивайте одинаковую задачу, а не названия технологий
При выборе между Flutter, React Native и отдельной разработкой для Android и iOS начните с описания продукта. Кто им пользуется, какое действие выполняет, какие устройства уже есть у аудитории? Нужны ли обе платформы в первой версии или это пока предположение? Без этих ответов сравнение легко превращается в обсуждение предпочтений разработчиков. Подготовьте одинаковый набор сценариев для каждого предложения: вход, просмотр данных, основное действие, ошибки и возвращение в приложение. Укажите языки, интеграции и ожидаемое поведение при плохой связи. Только после этого сравнивайте состав работ. Одинаковое количество нарисованных экранов ещё не означает одинаковый объём реализации и проверки.
Выясните, что действительно будет общим
Кроссплатформенный подход предполагает повторное использование кода между платформами, но полезно спросить, какие именно части планируется объединить в вашем проекте. Обсудите правила обработки данных, формы, навигацию и работу с внешними сервисами. Отдельно перечислите места, где поведение должно различаться. Документация React Native предусматривает платформенные файлы и модуль Platform для различающегося кода. Источник: «Platform-Specific Code». Практический вывод для заказчика: фраза «одна кодовая база» не заменяет перечень исключений. Попросите объяснить, кто будет поддерживать такие участки и как они попадут в общую проверку. Не закладывайте процент экономии только на основании названия выбранного подхода.
Проверьте интеграции до полного интерфейса
Составьте список внешних зависимостей: авторизация, карты, сканирование, связь с оборудованием, уведомления, действующая система компании. Для каждой запишите конкретного поставщика, нужный сценарий и ограничения доступа. Если у бизнеса уже есть обязательный сервис, сообщите об этом до оценки, а не после согласования дизайна. Flutter описывает platform channels для взаимодействия кода Flutter с кодом соответствующей платформы. Источник: «Writing custom platform-specific code». Это техническая возможность, а не обещание готовой интеграции с любым устройством. Попросите показать работоспособность самой неопределённой связки на целевом оборудовании. Заранее решите, что делать, если подходящего готового компонента нет или его поддержку нельзя подтвердить.
Опишите требования к поведению и скорости
Формулировка «должно работать быстро» слишком общая для выбора архитектуры. Назовите действия, где ожидание особенно мешает: поиск по каталогу, ввод в форме, открытие задания, обработка изображения. Укажите объём тестовых данных, устройства и состояние сети. Критерии согласуйте до прототипа, чтобы оценка не зависела от впечатления на демонстрации. Предположим, сотрудник склада сканирует позиции подряд. Для такого условного продукта важно проверить полный цикл, включая сохранение результата и обработку повторного сканирования. В другой условной задаче, записи на услугу, важнее понятный выбор и подтверждение. Это разные основания для проверки; утверждение, что одна технология всегда быстрее или удобнее, не заменяет измерение вашего сценария.
Учитывайте людей, которые будут развивать продукт
Спросите, кто отвечает за обе платформы, сервер, выпуск и исправления. Рассмотрите не только опыт первого исполнителя, но и возможность передачи работы. В предложении должны быть понятны состав команды, документация и способ подключения другого специалиста. Одна универсальная роль на бумаге не объясняет, как решать сложную проблему конкретной платформы. Если у компании уже есть команда, обсудите, что она сможет поддерживать самостоятельно и где потребуется помощь. Не выбирайте подход только ради знакомого названия языка. Полезнее разобрать будущие изменения: новый способ входа, дополнительный язык, интеграция с внутренней системой. Попросите объяснить путь такого изменения от требования до проверки и выпуска.
Сравните сопровождение, а не только первый выпуск
Запросите одинаковую структуру оценки: исследование, интерфейс, интеграции, тестирование, публикация, документация и поддержка. Отдельно отметьте неизвестные условия и то, как они будут проверены. Для каждого подхода выясните, какие изменения можно делать вместе, а какие потребуют самостоятельной работы на каждой платформе. Не считайте повторное использование кода автоматическим сокращением всей проверки. В плане приёмки перечислите устройства и сценарии для обеих платформ, включая обновление существующей установки. Для бизнеса в Узбекистане добавьте русский и узбекский интерфейсы, привычные форматы данных и работу менеджеров после обращения. Технологическое решение должно обслуживать этот процесс, а его название не является результатом проекта.
Запишите решение и условия его пересмотра
Итог выбора удобно уместить на одной странице: задача первой версии, сравниваемые варианты, результаты прототипа, принятые ограничения и ответственные за поддержку. Если доказательств недостаточно, выделите конкретный вопрос для дополнительной проверки. Не подменяйте его неопределённым обещанием разобраться уже в ходе основной разработки. Нативный подход может быть обоснован различающимися требованиями платформ, а общий код — совпадающими сценариями и подходящей командой. Это направления рассуждения, не универсальный рейтинг. В заключении попросите разработчика назвать условия, при которых рекомендация изменится. Для предметного обсуждения достаточно принести список основных действий, обязательных интеграций, целевых устройств и планируемых изменений продукта.
Вопросы заказчиков
Кроссплатформенная разработка всегда дешевле?
Нет. Объём зависит от общих сценариев, исключений для платформ, интеграций и поддержки. Сравнивайте предложения по одинаковым требованиям.
Flutter или React Native можно выбрать без прототипа?
Для понятных сценариев это возможно, но неопределённую критическую интеграцию лучше проверить отдельно до окончательного выбора и оценки.
Когда рассматривать отдельную нативную разработку?
Когда важные требования платформ заметно различаются или проверка показывает ограничения другого подхода. Решение нужно обосновать вашим сценарием и доступной командой.