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

И вот тут… понеслась телега в пляс:

Нативные приложения. Звучит круто: максимально интегрируются в систему, плавный интерфейс, доступ ко всем возможностям платформы, ощущение, что всё работает как надо. Но разрабатывать их долго и дорого. Плюс каждое обновление идёт через стор — а это ревью, задержки и куча бюрократии. И остаётся зависимость от Apple и Google: если что-то блокируется или накладываются ограничения — приложение фиг обновишь. А уведомления… А что уведомления? У всего есть своя кончина.

Хорошо, не натив. Тогда что? Нам нужно быстро накидать прототипчик или же на коленке собрать “лишь бы было”? Кроссплатформа — вот что нам нужно. Хороший подход: пиши один раз — собирай под всё (честно-честно). И вот что мы имеем:

Kotlin Multiplatform. Красавец, что позволяет нам писать всё на, как вы уже догадались, котлине. Он даёт возможность писать общий код для логики, но интерфейс всё равно пишется нативно. Но это было до Compose Multiplatform. Теперь пиши всё на котлине и радуйся. Это экономит силы, но команды на iOS и Android нужны. Ну или хотя бы тот, кто хорошо шарит в котлин и понимает специфику работы платформ.

Flutter. Позволяет писать один код и запускать его сразу везде. Тут нам помогает красавец Dart. Интерфейс выглядит одинаково, разработка идёт быстрее. Плюс ещё и работает это довольно шустро. Но это не системные элементы, а их имитация — и это иногда заметно. Хотя во многих случаях это даже плюс бизнесу: можно создавать интересные штуки там, где это реально сложно (тени на Android нативно - милости просим).

Это всё хорошо, но при этом ограничения сторов никуда не исчезают.

React Native. О, его многие не любят, некоторые даже думают, что это прокачанный WebView. Но он работает иначе. Сильно иначе. Под капотом он использует настоящие нативные компоненты, поэтому интерфейс ощущается ближе к нативному. Правда, управляется эта бравада через JS, bridge, что не делает погоды в пользу производительности. Хотя с новой архитектурой дела пошли получше. Плюс есть киллер-фича — возможность обновлять приложение напрямую через CodePush, не дожидаясь одобрения стора. Для бизнеса это ускоряет всё в разы. Но здесь есть и обратная сторона: часто приходится лезть в нативный код. Без знаний iOS и Android далеко не уедешь (с лишними волосами на голове тоже, но тут тссс…).

И вот теперь мы плавно подходим к PWA. Ссылку открыл, сделал парочку простых действий — и у тебя уже приложение на главном экране. Обновляется мгновенно, сторы не нужны. Но ощущается это довольно ненативно. Но я бы хотел, чтобы в будущем это развивалось. Ведь реально прекрасная технология, которая имеет все шансы закопать остальные способы разработки мобильных приложений. Но это моё имхо, так сказать (ну и немножко злорадство фронтендера во мне, хи-хи)

Кстати, тут есть ещё один подход, который можно использовать в приложениях — backend-driven UI. Когда интерфейс задаётся на сервере в виде некоторой схемы, а клиент просто его отрисовывает, используя уже реальные компоненты. Для бизнеса это удобно: можно довольно быстро менять содержимое экранов, запускать эксперименты, тестировать гипотезы без релизов. Но если архитектура выстроена плохо, то всё превращается в хаос, где никто не понимает, что происходит.

Казалось бы, всё? Нет, не всё. Что, если мы не будем держаться только одной из этих сторон? Есть много приложений, к примеру, которые по сути просто WebView с сайтом внутри. Даже без натива — просто берут Flutter или RN и вставляют туда веб.

Я говорю про другое. Мы делаем полноценное приложение, но часть функционала выносим в PWA и загружаем через WebView…. (продолжение в комментах)