Что выбрать для мобильного приложения: нативное или гибридное, плюсы и минусы
Что проверяют
Понимаете ли вы разницу между подходами и, главное, как выбор меняет вашу работу. Вопрос задают тестировщику не ради архитектурного спора: хотят услышать, как меняются матрица устройств, набор рисков и способ автоматизации.
Как отвечать
Сначала развести термины, их путают чаще всего:
- нативное: отдельный код под каждую платформу, интерфейс из системных компонентов;
- кросс-платформенное с собственным рендером или системными виджетами: общая логика и интерфейс, доступ к возможностям устройства через плагины;
- гибридное: веб-приложение внутри оболочки с браузерным движком;
- веб-приложение в браузере с установкой на устройство.
Дальше критерий: тяжёлая графика, фоновая работа, плотная работа с датчиками и офлайн тянут к нативу. Формы, каталоги, контент и быстрый выход сразу на две платформы тянут к общей кодовой базе.
Теперь про тестирование, ради этого вопрос и задан. В оболочке с браузерным движком поведение зависит от версии движка на устройстве, а автоматизация вынуждена переключать контексты и работать с веб-локаторами. В общей кодовой базе элементы нужно специально помечать идентификаторами, иначе дерево доступности для тестов неудобное. Общий код даёт и общий дефект сразу на обеих платформах, а платформенная специфика никуда не девается: разрешения, покупки, уведомления, поведение клавиатуры.
Где спотыкаются
Смешивают гибридное и кросс-платформенное и приписывают решениям с собственным рендером ограничения браузерного движка. Это разные вещи и по производительности, и по доступу к устройству.
Второе: отвечают как менеджер, про бюджет и сроки, ни слова не сказав о проверках. Вопрос задан тестировщику, и ждут ответа про риски и тестовую стратегию.
Третье: считают, что общая кодовая база отменяет прогон на обеих платформах. Навигация назад, вырезы экрана, жизненный цикл приложения, платные подписки и уведомления различаются, и регресс всё равно нужен на обеих.