Flutter-приложения: один код, два стора сразу

Flutter представляет собой фреймворк для интерфейсов от Google, написанный на Dart; он создаёт рабочие приложения для iOS, Android, веба и десктопа из единой кодовой базы. Он рисует интерфейс собственным движком отрисовки, поэтому одна и та же кнопка и одна и та же анимация перехода выглядят одинаково на обеих платформах.

Код компилируется в нативный код ещё до попадания в магазин; это не веб-страница, работающая в обёртке. Это различие важно, потому что по производительности и при проверке магазином приложения на Flutter оцениваются в той же категории, что и нативные.

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

Второй выигрыш: поддержка. Как только приложение выходит в релиз, отслеживание версий, обновления библиотек и совместимость с операционной системой идут через единую кодовую базу, что позволяет небольшой команде дольше держать приложение в порядке без роста штата.

Проверка простая: ведёт ли себя бизнес-логика приложения (формы, списки, оформление заказа, уведомления) одинаково независимо от платформы, или на каждой платформе она должна работать по-разному. Если верно первое, Flutter экономит реальное время; если верно второе, выигрыш быстро сокращается.

Flutter не решение любой мобильной задачи. Если приложение должно всего лишь показывать немного контента, а пользователь и так открывает его пару раз в день, PWA способна сделать то же самое гораздо дешевле; строить отдельное приложение для магазина в этом случае становится лишней тратой.

Если в команде уже есть сильные нативные разработчики, а объём приложения сильно завязан на аппаратные возможности конкретной платформы, переход на Flutter добавляет кривую обучения, а выигранное время остаётся ограниченным. В этом случае логичнее продолжать работу с существующей нативной командой.

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

Вторая ошибка: относиться к требованиям магазина (размер приложения, тексты разрешений, правила иконки) как к вопросу на потом, а не как к отправной точке. Как мы уже писали в статье о процессе публикации в App Store и Google Play, из-за этого даже хорошо собранное приложение на Flutter может быть отклонено с первого раза.

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

Такие места есть. Если приложение сильно опирается на дополненную реальность, продвинутую обработку камеры или доступ к специфичному для платформы оборудованию, именно для этой части может понадобиться нативный код через платформенные каналы. Flutter это поддерживает, но это не то же самое, что писать нативный код с нуля.

Есть и вопрос точного, пиксельного повторения языка дизайна каждой платформы. Для большинства коммерческих приложений пользователи разницу не замечают; для брендов с очень строгими визуальными правилами об этом стоит поговорить напрямую перед началом работы.

Производитель напольных покрытий хотел, чтобы его дилерская сеть проверяла остатки на складе и отслеживала заказы с телефона. Вместо создания двух нативных команд мы собрали приложение одной командой на Flutter; тот же интерфейс, та же бизнес-логика, релиз в оба магазина в один день.

Каждую функцию, которую дилеры просили потом, писали один раз и тестировали один раз. Две отдельные команды, работающие синхронно, замедлили бы этот цикл гораздо сильнее.

Единая кодовая база по-прежнему создаёт два отдельных пакета для App Store и Google Play, но исходный код один. Когда выходит обновление, оно может отправиться в оба магазина в один день, под одним и тем же номером версии.

Помимо снижения затрат на поддержку, это значит, что обе платформы остаются актуальными одновременно; ни одна платформа не отстаёт в ожидании функции.