Нативная, кроссплатформенная и webview разработка. Что изменилось к 2023 году?

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

В прежние годы клиенты, обращавшиеся к нам в Bright Mobile за разработкой, спрашивали про стек технологий: на чём мы пишем, как будет выглядеть результат, какова скорость работы приложений и т. д. С течением времени этот вопрос стал задаваться всё реже. Причин тому две.

Первая – развитие кроссплатформенной разработки. Раньше она была достаточно тормозной, и даже неподготовленный человек мог сходу определить по паре переходов, нативная ли тут разработка или кроссплатформенная. По сравнению с нативом задержка загрузки составляла плюсом 1-2 секунды. Сейчас она исчисляется милисекундами, и просто так натив от кроссплатформы сторонний человек уже не отличит. Кроссплатформенная разработка шагнула далеко вперёд, и я этому несказанно рад.

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

На нативе можно разработать что угодно – Kotlin на Android и Swift на iOS и предназначены для того, чтобы писать любые приложения под эти системы. Т. е. любую разработку, которую можно сделать на телефоне, можно без проблем реализовать на нативе. Но есть нюанс: кроме того, что вам придётся написать отдельное приложение для Android и отдельное – для iOS (и это абсолютно разный код, обычно требующий работы двух специалистов), потребуется ещё сделать серверную часть.

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

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

1. Разработка игры

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

2. «Тяжёлые» приложения

Пункт, вытекающий из предыдущего блока: всё, что требует серьёзной нагрузки на железо телефона, тоже требует натива, так как при выборе кроссплатформенной разработки тормоза будут куда заметнее.

3. Приложения с большим охватом

Те сервисы, которые имеют 500к+ скачиваний, нуждаются в нативе. Разумеется, о строгой шкале, когда иметь 499 999 пользователей в кроссплатформенном приложении можно, а при 500 000 нужно срочно переходить на натив, нет. Однако на основе анализа и собственного опыта знаю: чем больше пользователей в сервисе, тем больше эффект «бутылочного горлышка» — приложение тормозит всё больше, и для увеличения пропускной способности требуется разработка нативной части.

Важный момент: на натив переписывается не всё приложение, а только тормозящие экраны. Выяснить, какие именно, лучше заранее – ещё до того, как будет достигнут порог в 500к. А затем, после выяснения слабых сторон продукта, приниматься за рефакторинг и переписывание требовательных по нагрузке экранов. Кроссплатформа это позволяет, в ней можно вставить отдельные нативные блоки, экраны и функции. Так сделано даже у таких популярных сервисов, как, например, Facebook: не слишком популярные экраны они реализовали кроссплатформенно.

4. «Железные фишки»

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

Не стоит ориентироваться на это правило для огромного стартапа, где, к примеру, только на нескольких страницах есть геолокация: в этом случае куда правильнее выбрать кроссплатформенную разработку и сэкономить. А если в приложении всего пара-тройка экранов, и работа каждой основана на железе (например, NFC-чипа), лучше остановиться на нативе. В подобных продуктах, как правило, мало экранов и мало кода, поэтому при кроссплатформенной разработке экономия будет незначительной.

Под кроссплатформой я сейчас понимаю все фреймворки: Angular, Vue, React, Flutter, React Native и пр. Всё, что есть на рынке, работает, в принципе, по одной и той же технологии. Когда такой вариант применим наиболее всего?

За пять лет с момента написания предыдущей статьи приложения на кроссплатформенной разработке стали чаще всего использоваться в следующих сферах.

1. Бизнес-приложения.

Всё, что связано с корпоративной связью, личными кабинетами, сервисами заказа услуг – как наше коробочное решение для маркетплейсов, которое тоже написано на кроссплатформе. Основной функционал у него связан с отображением списка, элементов, заполнением формы, самое сложное – чат, который работает по сокетам.

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

2. Однопользовательские приложения

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

3. Приложения менее 500к пользователей

Причину уже объяснял выше в аналогичном разделе про натив, связана она с повышенной нагрузкой на приложение при росте аудитории.

4. Всё, что связано с e-commerce

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

Вывод: кроссплатформенная разработка закрывает примерно 80% стартапов выше описанного типажа.

И наконец – о том, что такое вебвью и почему оно загибается. Для начала – о применимости подобного варианта разработки.

1. Максимально простые сервисы

Эта история про формы обратной связи, уведомлялки и прочее, что не грузит ни телефон, ни сервер и служат для простого сбора данных. Например, если у вас компания с 20-ю ремонтниками, через такую формочку они могут заполнять отчёт о выполненной работе, который потом падает, например, в Битрикс24. Всё это в принципе можно реализовать в виде сайта, телеграм-бота или даже на Гугл. Формах, и тут уже поднимается вопрос необходимости самого приложения.

2. Тесты идеи

Пожалуй, самое распространённое сегодня направление. Идея есть, а понимания механики сервиса и его маркетинга нет. В таких случаях актуально сделать самое простое и дешёвое приложение с минимальной бизнес-логикой, тестировать и делать выводы. Уже потом, на базе результатов, делаете полноценное приложение на нативе или кроссплатформе – в зависимости от того, что подойдёт больше.

3. Проекты с подменой контента

Webview – это некий «мини-браузер», который публикуется в App Store/Google Play и, по сути, отображает мобильную версию сайта, хранящуюся на сервере. При том или ином изменении логики не нужно постоянно перезаливать приложение в стор – достаточно поменять мини-сайт на стороне сервера, а опубликованная оболочка остаётся прежней.

По большей части подобная схема применяется для мошеннических целей. Сначала публикуется приложение под благовидным предлогом, например, связанной с доставкой еды. Стор его модерирует, публикует – а создатели быстро меняют сайт, подключенный к оболочке, и там вдруг оказывается какой-нибудь тотализатор, магазин веществ или что-то ещё запрещённое условиями стора и/или законодательством.

Зная это, сторы чаще всего очень сильно придираются к вебвью-приложениям и, как правило, подобные простенькие сайты попросту срезают и не публикуют. Под предлогом того, что в приложении должен быть хоть какой-то минимальный функционал реализованный в самой оболочке – авторизация, push-уведомление и прочее, чего в подавляющем числе оболочек, продающихся на кворке за 10 тыс нет.

Это следует иметь в виду основателям стартапов, которые не хотят тратиться на нативную / кроссплатформенную разработку и заказывают вебвью подешевле: вполне может случиться так, что опубликоваться в итоге не получится, и такая экономия выйдет боком. Доработка оболочки – дело неблагодарное, за него программисты берутся крайне редко. Большинство отказывается, кто-то выставляет странные чеки, а потом ещё возникают проблемы с привязкой к серверу… Если у вас нормальное приложение, а не скам, лучше выберите кроссплатформенную разработку у программиста подешевле – так у вас хотя бы будет какая-то гарантия, что вы сможете выложиться в стор.

Причина вымирания webview логично вытекает из сказанного выше: простое приложение можно достаточно дёшево сделать и на кроссплатформе, а проблем с модерацией у него не будет. Что касается тестов идей – сегодня стартаперы куда чаще запускают либо мобильные версии сайтов, либо прочие средства, с публикацией мобильного приложения не связанные. Рынок webview сжимается всё больше, и разработчики, которые занимались исключительно этой областью, рано или поздно уходят в кроссплатформу. Оставшиеся зачастую в нюансах разработки вебвью разбираются слабо, а денег просят всё больше – так что, с учётом всех рисков и недостатков, заказывать вебвью сегодня становится нецелесообразно.

Больше полезной информации в канале про разработку стартапов.