Для новых, небольших(и средних) проектов можно рассматривать эти технологии(flutter и rfw), но для крупных (новых и уже реализованном на 'нативном' стеке) проектов, для крупных компаний, где не нужно экономить я бы не рекомендовал их использовать.
Минусы, которые не позволяют нам использовать их(flutter и rfw): 1. Фреймворк Flutter достаточно молодой. 4 декабря 2018 года на конференции Flutter в Лондоне была выпущена версия кроссплатформенного фреймворка Flutter 1.0 Что накладывает риски в найме специалистов со знаниями Flutter(Dart) и в наличие достаточной документации по нему.
2.
Open-source проект Google, риск запрета на использование или ввода неких ограничений Flutter — open-source проект (лицензия BSD), что формально делает его независимым от политики Google. Dart (язык Flutter) — также open-source, разработку можно продолжать даже без поддержки Google.
Прямого запрета на использование Flutter пока нет, но риски есть, особенно если учесть сложную геополитическую ситуацию. Также ничто не мешает компании Google сделать из open-source проектов Flutter и Dart коммерческие проекты. Flutter - это глубоко интегрированное решение, если будет запрет на его использование, то это приведёт к необходимости переписывания 'с нуля'. Основной риск - обновления Flutter SDK, если GitHub/Dart-репозитории станут недоступны.
3.
Объёмы наших текущих проектов мобильных приложений 200 000 - 300 000 строчек кода. Нет автоматизированных средств конвертации кода из нативного(iOS/Kotlin) представления во Flutter проект. Нельзя напрямую конвертировать существующие iOS/Android-проекты в Flutter. Что бы просто переписать текущие проекты на Flutter требуются значительные трудозатраты.
4.
Server Driven UI (SDUI) - это нативное(!) кроссплатформенное решение. Нативное решение - это sdk от 'производителя'(н.р. Apple/Google) предназначенное для разработки приложений под конкретную платформу.
Flutter - не нативный UX(н.р. для iOS), ограниченный доступ к некоторым специфичным АПИ, больший размер приложения по сравнению с нативными, производительность ниже, если нужна поддержка новой фичи iOS/Android придётся ждать пока Google не добавит её во Flutter.
LiveView - это для web-разработки(получение HTML-страницы). Упор же этой статьи делается на разработку мобильных приложений. Ну а когда у вас условно 2(ios+android) мобильных приложения работают на единой логике с бэком возникает логичный вопрос - почему бы и web не перевести на единые 'рельсы'?
В комментарии выше писал, что SDUI это нативное(!) кроссплатформенное решение, простыми словами Надстройка над нативной реализацией. То есть разработчик делает ровно то что и делал раньше, но .. с применением SDUI он теперь проявляет командный подход, помогает заказчику удешевить разработку, сделать доставку изменений до клиентов максимально быстрой, ..
'К сожалению' то что разрабатывают отдельные организации является их интелектуальной собственностью и они вправе решать что сней делать - делать ли своё решение открытым или нет.
Есть к примеру хорошее решение от Яндекса: https://divkit.tech/ru/ Кстати если кому-то интересно можете его использовать. Мы его рассматривали, но для нас оно слишком громоздкое, неподходящий стек и 'сложность' внесения правок под наши 'пожелания'.
А это не очень тяжело поддерживаемая система? SDUI можно представить как НАДСТРОЙКУ над нативным кодом или вашей обычной реализацией. Со тороны бэка:
появляется некий 'переводчик' Со стороны фронта на примере реализации UI-компонента:
условно сначала пишеться нативный код компонента
далее эта реализация дорабатывается до соответствия технологии SDUI(условно - следование некому протоколу)
Из этого пояснения кажеться, что мы видим наоборот удорожание разработки :) Но нет.
С технологией SDUI разрабатывается общий механизм конструирования экранной формы. То есть уменьшаем время на разработку и сводим на нет возможность ошибок.
С формированной на 100% компонентной базой нужно только писать json инструкции. А кто может писать эти json инструкции? Правильно - не какой то очень специализированный специалист, а условно любой. То есть снижаем потребность в большом количестве высококвалифицированных специалистов(условно нам достаточно иметь junior+, middle разработчиков).
Для чего это нужно ? Ответ 'банальный' - удешевить и сделать более качественной разработку.
Мне кажется эту систему со временем будет очень тяжело поддерживать и что то оттуда выпиливать. Поддерживать любую мало мальски большую кодовую базу на любом языке программирования с таким уклоном .. тяжело :)
Но .. повторю тезис из статьи про релизы мобильных приложений. Выпустить новую фичу или срочное исправление бага ооочень долго по времени через стандартные механизмы магазинов распространения. Гораздо проще и быстрее написать одну инструкцию и получить ежесекундное обновление в приложении. А с учётом того что SDUI инструкции(логика) принимаются на любой платформе и она 'одна' мы получим появления обновления сразу на всех фронтах вашего проекта То есть c технологией SDUI пишем логику в единственном экземпляре, а она применяется для всех фронт приложений проекта.
Если вам нужно быстро и дёшево получить проект сразу на трёх платформах (iOS / Android / Web) React Native выглядит довольно перспективно.
Но банковское приложение — это долго играющий проект.
Используя React Native вы полностью попадаете под его зависимость.
А с этим вы получаете целый 'букет страхов' — Что будет с React Native через год, два, 10 лет...? Вспоминая Cordova… Доступ к техническим возможностям устройства? Что будет с проектом после появления новой версии iOS SDK? Обновления CocoaPods? и т.д.
В принципе пункт '3. Нужно определиться с подходом разработки под iOS (нативный или альтернативный).' как раз об этом.
Статья показывает развитие мобильного приложения МКБ под платформу iOS.
Статья является обзорной и не закладывалась, чтобы рассказать сразу обо всём.
Мы стремились заинтересовать читателей.
Далее будет серия небольших технических статей.
Если есть вопросы по разработке приложений под iOS(с точки зрения программирования ) — задавайте — с удовольствием отвечу.
Для новых, небольших(и средних) проектов можно рассматривать эти технологии(flutter и rfw), но для крупных (новых и уже реализованном на 'нативном' стеке) проектов, для крупных компаний, где не нужно экономить я бы не рекомендовал их использовать.
Минусы, которые не позволяют нам использовать их(flutter и rfw):
1.
Фреймворк Flutter достаточно молодой.
4 декабря 2018 года на конференции Flutter в Лондоне была выпущена версия кроссплатформенного фреймворка Flutter 1.0
Что накладывает риски в найме специалистов со знаниями Flutter(Dart) и в наличие достаточной документации по нему.
2.
Open-source проект Google, риск запрета на использование или ввода неких ограничений
Flutter — open-source проект (лицензия BSD), что формально делает его независимым от политики Google.
Dart (язык Flutter) — также open-source, разработку можно продолжать даже без поддержки Google.
Прямого запрета на использование Flutter пока нет, но риски есть, особенно если учесть сложную геополитическую ситуацию.
Также ничто не мешает компании Google сделать из open-source проектов Flutter и Dart коммерческие проекты.
Flutter - это глубоко интегрированное решение, если будет запрет на его использование, то это приведёт к необходимости переписывания 'с нуля'.
Основной риск - обновления Flutter SDK, если GitHub/Dart-репозитории станут недоступны.
3.
Объёмы наших текущих проектов мобильных приложений 200 000 - 300 000 строчек кода.
Нет автоматизированных средств конвертации кода из нативного(iOS/Kotlin) представления во Flutter проект.
Нельзя напрямую конвертировать существующие iOS/Android-проекты в Flutter.
Что бы просто переписать текущие проекты на Flutter требуются значительные трудозатраты.
4.
Server Driven UI (SDUI) - это нативное(!) кроссплатформенное решение.
Нативное решение - это sdk от 'производителя'(н.р. Apple/Google) предназначенное для разработки приложений под конкретную платформу.
Flutter - не нативный UX(н.р. для iOS), ограниченный доступ к некоторым специфичным АПИ, больший размер приложения по сравнению с нативными, производительность ниже, если нужна поддержка новой фичи iOS/Android придётся ждать пока Google не добавит её во Flutter.
LiveView - это для web-разработки(получение HTML-страницы). Упор же этой статьи делается на разработку мобильных приложений. Ну а когда у вас условно 2(ios+android) мобильных приложения работают на единой логике с бэком возникает логичный вопрос - почему бы и web не перевести на единые 'рельсы'?
Почему?
В комментарии выше писал, что SDUI это нативное(!) кроссплатформенное решение, простыми словами Надстройка над нативной реализацией.
То есть разработчик делает ровно то что и делал раньше, но .. с применением SDUI он теперь проявляет командный подход, помогает заказчику удешевить разработку, сделать доставку изменений до клиентов максимально быстрой, ..
'К сожалению' то что разрабатывают отдельные организации является их интелектуальной собственностью и они вправе решать что сней делать - делать ли своё решение открытым или нет.
Есть к примеру хорошее решение от Яндекса: https://divkit.tech/ru/
Кстати если кому-то интересно можете его использовать.
Мы его рассматривали, но для нас оно слишком громоздкое, неподходящий стек и 'сложность' внесения правок под наши 'пожелания'.
появляется некий 'переводчик' Со стороны фронта на примере реализации UI-компонента:
условно сначала пишеться нативный код компонента
далее эта реализация дорабатывается до соответствия технологии SDUI(условно - следование некому протоколу)
Из этого пояснения кажеться, что мы видим наоборот удорожание разработки :) Но нет.
С технологией SDUI разрабатывается общий механизм конструирования экранной формы.
То есть уменьшаем время на разработку и сводим на нет возможность ошибок.
С формированной на 100% компонентной базой нужно только писать json инструкции.
А кто может писать эти json инструкции? Правильно - не какой то очень специализированный специалист, а условно любой.
То есть снижаем потребность в большом количестве высококвалифицированных специалистов(условно нам достаточно иметь junior+, middle разработчиков).
Но .. повторю тезис из статьи про релизы мобильных приложений.
Выпустить новую фичу или срочное исправление бага ооочень долго по времени через стандартные механизмы магазинов распространения. Гораздо проще и быстрее написать одну инструкцию и получить ежесекундное обновление в приложении.
А с учётом того что SDUI инструкции(логика) принимаются на любой платформе и она 'одна' мы получим появления обновления сразу на всех фронтах вашего проекта
То есть c технологией SDUI пишем логику в единственном экземпляре, а она применяется для всех фронт приложений проекта.
Если вам нужно быстро и дёшево получить проект сразу на трёх платформах (iOS / Android / Web) React Native выглядит довольно перспективно.
Но банковское приложение — это долго играющий проект.
Используя React Native вы полностью попадаете под его зависимость.
А с этим вы получаете целый 'букет страхов' — Что будет с React Native через год, два, 10 лет...? Вспоминая Cordova… Доступ к техническим возможностям устройства? Что будет с проектом после появления новой версии iOS SDK? Обновления CocoaPods? и т.д.
В принципе пункт '3. Нужно определиться с подходом разработки под iOS (нативный или альтернативный).' как раз об этом.
Хорошая статья про использование React Native:
habr.com/ru/company/qlean/blog/416097
Статья является обзорной и не закладывалась, чтобы рассказать сразу обо всём.
Мы стремились заинтересовать читателей.
Далее будет серия небольших технических статей.
Если есть вопросы по разработке приложений под iOS(с точки зрения программирования ) — задавайте — с удовольствием отвечу.