Что такое нативное приложение
Что такое «Нативное приложение»?
JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.
Приложения на Titanium – это не сайты, которые чудесным образом обернуты в приложения.
Что ты имеешь в виду под «Нативной» разработкой?
А что делает приложение нативным?
Что такое хороший User Experience?
Выглядит и ведет себя ожидаемо
iOS, Android и Windows имеют различные требования к дизайну (iOS, Android,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана. 
Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView.
Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.
Натив или кроссплатформа? Детальный разбор простым языком
Немного знаний терминологии не повредит, чтобы иметь больше совместного контекста. Постараюсь не быть занудой.
SDK — software development kit — инструментарий разработчика. Говорят например, — AppStore SDK — набор инструментов для реализации платежей и подписок в приложении. Или Android SDK — совокупность более мелких SDK для разработки под всю платформу.
API — это программный интерфейс, (тяжело объяснять простыми словами оказывается). Руль — физический интерфейс к колёсам, коробка передач — к двигателю, мы дергаем за них, чтобы машинерия внутри сделала для нас более сложную работу через простой для восприятия интерфейс. Программные интерфейсы — наборы функций, объектов, используя которые программисты выполняют сложную работу более простыми действиями.
Поскольку сухой разбор преимуществ и недостатков той или иной технологии — пустая трата времени, будем честны, из любой технологии можно сделать какашку и конфетку, вопрос лишь какой ценой, поэтому для развития осознанного понимания, зайдем чуть издалека.
Так или иначе, клиент любого бизнеса, пожелавшего открыть для себя вожделенную айтишечку, доступен через 3 окошка:
Также мы не рассматриваем устройства носимой электроники, интернета вещей, экранов холодильников, различных embedded систем — уж очень они специфичны.
На заре широкого коммерческого успеха мобильных гаджетов, некто по фамилии Джобс, отстаивал идею о том, что персональный смартфон — это всего лишь окошко к всемирной паутине, которое всегда с собой. Круто же звучит! Вот что он говорил:
Полноценный движок Safari уже присутствует внутри iPhone. То есть, вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете, что? Для этого не нужен SDK! У вас уже все есть для написания невероятных приложений для iPhone, если вы знаете, как создавать программы, используя современные веб-стандарты.
Есть предположение, что изменить взгляд Джобсу помог Джонни Айв, убедив его в том, что устройства эппл без нативных сторонних приложений не будут доступны для создателей контента, плюс от этого платформа потеряет эксклюзивность. В тоже время, в кулуарах Гугл зрел андроид и у менеджмента не было особого мнения на этот счет.
Собственно, к чему эта лирика. Исторически, мы имеем два основных способа доставки приложения пользователю:
-Нативное приложение — созданное с использованием инструментов разработки вендоров: Apple/Google и распространяемое через магазины приложений. Для разработки под Apple актуальны технологии: UIKit, SwiftUI + богатый iOS SDK, язык программирования Swift (и для особых случаев старичок Objective-C)Для Андроид соответственно — Android SDK, Jetpack Compose, языки: Java 8, Kotlin
Веб-приложение, использующее браузер в качестве среды выполнения и ограниченного доступа к ресурсам девайса (я специально не называю веб-приложение сайтом, так мы в терминах отделяем статические странички от динамичных, наполненных различной бизнес-логикой, приложений). К ним же относятся так называемые WebView — приложения, обернутые тонким слоем нативного кода, использующего SDK браузера для открытия веб-приложения, также распространяются через сторы.На ладан дышащие представители этого вымирающиего семейства — Apache Cordova и Ionic. Они не скрывают свое основное назначение — быстрое прототипирование приложений. Для них актуальны классические веб технологии — HTML, CSS, Javascript. Сюда же попадают поделки из no-code конструкторов типа GlideApps и его аналогов.
Оба подхода стоят диаметрально противоположно друг другу по ряду критериев:
Промеж первых двух, с недавних пор, расположись гибридные технологии, которые в настоящий момент чаще всего подразумеваются как кроссплатформенные:
Гибридные, компилируемые в нативный код — приложения написанные с использованием сторонних инструментов разработки, языков программирования, которые имеют свой набор библиотек, связывающих программные интерфейсы платформенных SDK с собственными интерфейсами или полностью заменяющие их.
Типичные представители этого семейства: React Native, Native Script, Electron.
Пока мы не убежали далеко, хочу немного шокировать нетехническую публику — самая кроссплатформенная технология, он же язык программирования, внимание, — C++! Та-да-а-ам! И как ни странно, он очень широко используется для создания полностью нативных кроссплатформенных модулей. Никаких компромиссов! Только хардкор! Ведь наши приложения, это не только кнопочки и списки. Обработка сотен точек на картах, базы данных с особыми возможностями синхронизации совместного доступа к данным, криптография, доставка и обработка видео в реальном времени, ежесекундные данные котировок, которые мы хотим доставлять молниеносно для десятков биржевых тикеров одновременно и многое другое. Никто не пишет эту логику дважды или трижды под каждую платформу.
Главный вопрос при выборе технологии (безотносительно иных бизнес целей) — опыт какого качества мы хотим подарить пользователю. И вот несколько критериев, влияющих на пользовательский опыт:
Говоря образно, по степени абстрактности к конечной мобильной платформе, технологии можно разделить так:
Кроссплатформенные технологии, в первую очередь, хотят завлечь нас преимуществами единой кодовой базы. С этим трудно спорить:
Сравните 2 кусочка кода, описывающих карточку с картинкой:
Команды нативных разработчиков часто разбавляют C/C++ программистами. Они пишут кроссплатформенные модули для разных задач в основном не связанных непосредственно с бизнес логикой.
На старте с нуля ему нет равных в качестве продукта к скорости разработки. 2-3 разработчика способны наковырять безумное количество фич в кратчайшие сроки и выпустить продукт. При этом look-and-feel, производительность будут более чем приемлемыми. Большое количество библиотек решат множество задач типовой функциональности. Я бы назвал flutter серебряной пулей, но. надо кое-что иметь в виду.
Технология предназначена для создания UI! Как и язык программирования Dart.
Выдержка из википедии в доказательство о том, что есть флаттер на самом деле:
Flutter is an open-source UI software development kit created by Google.
Разработка с этим SDK мне всегда напоминала письмо из Простоквашино:
На личном опыте проверено, что в процессе развития продукта скорость нативной разработки со временем возрастает, а кроссплатформенной убывает. Это обусловлено тем, что в начале требуется больше усилий для сборки архитектуры и наработке кода для 2х проектов, нежели для одного. Пока умудренные в особенностях своих платформ, кодеры скрупулезно собирают базовые джентельменские наборы для любого нативного приложения, их коллеги по кроссплатформенному цеху возможно уже готовятся выпускать MVP. Всё меняется на зрелой стадии продукта.
Вот список бед на кроссплатформе, которые на поздней стадии сожрут больше денег, чем на старте:
Дайте знать, если хотите продолжение про KMM и Xamarin, жду вас и ваши мнения в комментариях!
Канала в телеге нет, но если что, пишите в личку
Что такое нативное приложение
Что такое нативная и кроссплатформенная мобильная разработка, чем они отличаются, как сделать выбор. Объясняет Surf.
«А зачем мне вообще в этом разбираться, — скажет заказчик. — Приду к разработчику, он знает, как лучше». И да, и нет. Разработчик объяснит технические детали и добавит недостающие элементы в картинку. Но он вряд ли станет беспристрастно оценивать ваш бизнес, анализировать бюджет и сроки. Кроме того, даже у профи могут быть личные пристрастия и привычки в работе.
Поэтому мы решили рассказать, что такое нативная и кроссплатформенная мобильная разработка, чем они отличаются и как между ними выбирать. В этой статье не будет сложных технических терминов — только знания, которые помогут вам понять разницу и выбрать подходящее решение.
Кто мы: Surf более 10 лет занимается разработкой мобильных приложений. Среди наших клиентов Росбанк, Магнит, KFC, «Лабиринт» и другие флагманы индустрии.
Натив и кроссплатформа: что это вообще такое
Это два типа разработки. Нативное приложение создаётся для конкретной операционной системы на языке программирования, который ей понятен. Пишутся два отдельных кода для двух ОС.
В случае кроссплатформы программисты используют фреймворки — программные каркасы, на которые затем вешают необходимые функции. Фреймворки универсальные — с их помощью создают приложения сразу для нескольких ОС. Код один, а систем много.
Кроссплатформенная разработка — относительно новое явление. И в этом есть как плюсы, так и минусы. С одной стороны, репутация фреймворков пока кажется ненадёжной. С другой — они создавались и тестировались с учётом опыта, который накопила к этому времени сфера мобильной разработки.
Например, первое устройство на Android вышло в 2008 году, а кроссплатформа Flutter стартовала только в 2017. Но её создатели смогли учесть накопившиеся боли коллег, упростили и оптимизировали подходы к разработке. Теперь многие вещи делаются буквально «из коробки», экономя время и нервы разработчика.
Натив: что это, кому подходит, примеры
Программирование в нативной среде ведётся на нескольких языках. Для Android это Kotlin и Java, а для iOS — Swift и Objective-C.
Нативная разработка — мощный инструмент. Подходит для тех, у кого мобильное приложение — основной канал продаж, и большой бюджет на развитие.
Плюсы нативного подхода
Система лучше понимает свой язык. С приложением, написанным специально под iOS или Android, будет меньше технических сложностей, в том числе с обновлениями. Его проще оптимизировать, сделать быстрее или легче. А чем меньше весит приложение, тем охотнее его скачивают пользователи.
Никаких ограничений: можно смело браться за реализацию любых идей, связанных с работой устройства — камерой, GPS, сенсорами, файловой системой устройства и так далее.
В нативной разработке намного больше специалистов — нет проблем с тем, чтобы найти сотрудников на проект или просто с кем-то посоветоваться.
Нативные приложения хороши всем, кроме стоимости. Это дорогой проект: для каждой ОС придётся разрабатывать свою логику, интерфейс и вёрстку. Под каждую платформу нужно держать отдельный штат разработчиков и тестировщиков. В зависимости от региона зарплата опытного мобильного разработчика начинается от 90 000 рублей, а у старшего специалиста может достигать 350 000 рублей.
Итог: нативное приложение оптимально для конкретной операционной системы, меньше весит, быстрее работает и даёт все возможности для реализации сложных функций. Но будьте готовы к большим расходам.
Например: «Лабиринт» и «Бетховен»
Нативная разработка точно нужна крупным компаниям, которые собираются создавать продукт со сложным каталогом и многоступенчатой вложенностью. Так мы создавали приложение для книжного интернет-магазина «Лабиринт». Это крупнейший проект с большой базой лояльных клиентов. Мобильное приложение для «Лабиринта» — важнейший канал продаж. Поэтому мы сначала разработали приложение для iOS, включая версию для айпада, и затем специально для Android.
Другой пример эффективного использования нативной разработки — магазин зоотоваров «Бетховен». За видимой простотой приложения — главная, каталог, корзина, оформление заказа, оплата — скрывается большая работа. Surf добавил каталог с фильтрами, голосовой поиск, развёрнутый профиль пользователя с программой лояльности и многие другие функции.
Оба приложения можно было сделать на Flutter, и пользователи не увидели бы разницы. Однако мобильные приложения настолько важны для обеих компаний, что они не хотели идти на компромиссы. Немалые инвестиции оправдали себя — получились флагманские приложения в своих категориях. Конверсия приложения «Бетховена» — более 15%, это очень высокий показатель для отрасли. А приложение «Лабиринта» стало для магазина одним из основных каналов продаж.
Кроссплатформа: что это, кому подходит, примеры
На рынке представлено много кроссплатформ: React Native, Xamarin, PhoneGap, Titanium, Ionic, Flutter. Однако глобально выбор сводится к двум вариантам: React Native и Flutter. Это наиболее популярные и развитые фреймворки. Для них быстрее и проще найти разработчика.
Оба решения дают качественный пользовательский опыт. В большинстве случаев существенной разницы между ними нет, но мы отдаём предпочтение Flutter. И не мы одни: к апрелю 2020 года его опробовали больше двух миллионов разработчиков. 500 тысяч заявили, что используют фреймворк ежемесячно. 92% высоко оценили Flutter и отметили, что планируют работать с ним дальше.
При работе с кроссплатформенным приложением пользователь должен воспринимать его как нативное — плавные анимации, высокая скорость работы, работа с жестами. С этим пока целиком справляется только Flutter.
В каких случаях стоит выбрать кроссплатформу
Вы небольшая компания. Мобильное приложение вам необходимо, но тратить миллионы на его разработку нет возможности.
Вы представляете крупную компанию, но именно по вашему проекту бюджет ограничен. Например, у него вторичная роль в бизнесе, как в случае приложения для водителей Яндекс. Такси, которое сделали на Flutter. Специалистам Яндекса требовалась iOS-версия приложения Таксометр, которое водители используют для приёма заказов. На разработку с нуля было всего 2,5 месяца, а само приложение должно было интегрироваться с актуальными версиями Android. Нативное приложение не подходило из-за сроков разработки, не получилось бы добиться одинакового поведения обоих приложений, нельзя использовать общую библиотеку компонентов. Поэтому приложение сделали на кроссплатформе.
У вас стартап и нужно сделать MVP (минимально жизнеспособный продукт) быстро и эффективно. Тот случай, когда чем быстрее сделаете и меньше денег потратите, тем лучше.
Приложения для разных ОС получаются практически одинаковыми. Так часто бывает в ритейле. Функции и пользовательские сценарии, программы лояльности, каталог, онлайн-магазин — всё одинаковое. Нет смысла просто дублировать приложения.
95% ваших пользователей сидят на одной ОС. Содержать отдельную команду и поддерживать приложение ради 5% дорого и нецелесообразно. Так случилось с нашим корпоративным приложением для KFC. У 95% сотрудников был Android, а у 5%, среди которых менеджеры и управляющие ресторанами, — iOS. Можно раздать сотрудникам корпоративные андроиды, но получится дорого и неудобно. А создавать два нативных приложения означает вдвое увеличить бюджет. Подходящим решением стало кроссплатформенное приложение на Flutter.
Дешевле не значит хуже: почему кроссплатформа экономичнее
Нативные приложения требовательны в разработке. Нужно синхронизировать две команды и закладывать двойной бюджет практически на всё: тестирование, релиз, обновления.
В случае кроссплатформы можно переиспользовать основную часть кода, а бизнес-логика, интерфейс и вёрстка почти не требуют изменений. Меньше расходы, компактнее команда разработчиков, короче показатель time-to-market — с помощью Flutter можно выпустить продукт на рынок за 2–3 месяца. Можно быстрее запускать новые функции и обновления, то есть зарабатывать с помощью приложения больше и быстрее. По нашим подсчётам, экономия бюджета на Flutter составляет до 40%.
Например: Росбанк Бизнес
Кросс-платформа подходит не только для заведомо бюджетных проектов. На ней отлично можно создавать сложные и дорогие приложения. Так Surf создал Росбанк Бизнес — первое в России и второе в мире банковское приложение на Flutter. Мы выбрали этот фреймворк во многом благодаря скорости запуска, критически важной для заказчика.
6 вещей, которые нужно знать при выборе мобильной разработки
1. Натив — два кода под две системы. Кроссплатформа — один код под несколько ОС.
2. Нативная разработка под конкретные операционные системы — хорошее, но дорогое и более медленное решение.
3. Кроссплатформы подходят, когда есть ограничения по срокам и бюджету, потому что можно создать одно предложение вместе двух отдельных.
4. Кроссплатформа позволяет сэкономить до 40% бюджета и сокращает показатель time-to-market.
5. У современных кроссплатформенных фреймворков широкие возможности: на них можно делать сложные продукты, которые с точки зрения пользователя неотличимы от нативных приложений.
6. Кроссплатформ сегодня много, но Flutter по пользовательскому опыту превосходит аналоги, а популярность фреймворка среди разработчиков растёт. Поэтому, если вы выбрали кроссплатформу, смотрите в сторону Flutter.
Подробнее о нашем опыте разработки на Flutter читайте в блоге Surf.
Нативная разработка, React Native и Flutter: критерии выбора
Уже на стадии проектирования мобильного приложения важно понимать, какой язык выгоднее использовать для конкретного проекта. Наряду с нативной разработкой (например, для iOS — Swift или Objective-C, для Android – Java или Kotlin), используются кроссплатформенные фреймворки, такие как React Native и Flutter. Мы в SimbirSoft предлагаем несколько критериев, которые помогут в выборе как бизнесу, так и мобильному разработчику.
Проблема выбора
В мире уже около пяти миллиардов смартфонов, по разным оценкам, до 80% из них используют операционную систему Android, и менее 20% – iOS. И все же в каждой стране есть свои особенности, так, в США более 65% смартфонов работают на iOS. При создании мобильных приложений чаще всего требуется выпустить версии как на iOS, так и на Android. Для этого можно обратиться к нативной или кроссплатформенной («гибридной») разработке.
Нативная разработка – это классическое решение, которое требует писать приложения под каждую платформу по отдельности, используя разные языки и учитывая особенности каждой платформы. При создании нескольких версий над проектом одновременно работают несколько команд.
Благодаря кроссплатформенным фреймворкам, появилась возможность «убить двух зайцев» разом и подготовить версии для iOS и Android с помощью одного инструмента. Среди фреймворков особенно широкое распространение получили:
— React Native от Facebook
для приложений iOS, Android и Windows
использует язык JavaScript и библиотеку React.js как основное средство разработки.
— Flutter от Google
для приложений Android, IOS и Fuchsia (подробнее см. нашу статью на Хабре)
использует язык Dart, который также служит для веб-программирования.
Популярность React Native и Flutter растет, хоть и с разной скоростью, согласно статистике Google Trends.
Нативная разработка
Как нативная, так и кроссплатформенная разработка имеют свои особенности. Мы использовали оба подхода в практике мобильного подразделения mobile.SimbirSoft. В числе преимуществ нативной разработки можно отметить следующие:
Гибридная разработка
Кроссплатформенные фреймворки «подгоняют» приложение под несколько операционных систем, поэтому нет необходимости создавать уникальные элементы для каждой платформы. В результате:
Критерии выбора Native, React Native и Flutter
Для бизнеса
1. Доступность
Некоторые компании, когда обращаются к нам для разработки мобильных приложений, отмечают стоимость как один из наиболее весомых для них критериев. При этом стоимость и потребность в специалистах зависят от способа разработки.
Как правило, мобильная студия располагает достаточными ресурсами для нативной разработки приложения любой сложности.
React Native и Flutter
На рынке меньше специалистов по этим направлениям. Возможны сложности при разработке крупных приложений.
Мы рекомендуем бизнесу нативные технологии, когда приложение рассчитано на продолжительную работу (иначе говоря, “срок жизни”). Также это выгодно при наличии потребности в высокой производительности, сложном интерфейсе и анимации, низком энергопотреблении, интеграции со сторонними ресурсами (API и др.). Нативные приложения более выгодны в перспективе за счет снижения затрат на техническую поддержку.
Кроссплатформенные технологии рекомендуем для быстрой проверки гипотез, разработки прототипов и приложений с явным ограничением срока эксплуатации, например, разработанных для определенных мероприятий.
Памятка для бизнеса:
для сложных приложений – рекомендуем нативную разработку;
для простых приложений – гибридную.
2. Скорость + соответствие задаче
Время вывода на рынок (time-to-market) определяется, в первую очередь, размером доступной команды и особенностями мобильного приложения.
Работа с кроссплатформенными фреймворками может оказаться выгоднее и быстрее, если приложение простое, с одинаковым UI, без платформо-специфичных деталей, таких как доступ к камере, работа с файловой системой и отпечатками пальцев, runtime permissons. Здесь гибридная разработка позволяет сэкономить время за счет вторичного использования практически всего кода и UI под две платформы. Однако, при необходимости создания сложных кастомных view кроссплатформенная разработка замедляется.
Говоря о времени разработки мобильного приложения, важно понимать, что не существует “среднего срока по больнице”. Например, мы в своей практике выпустили банковское мобильное приложение за 100 дней, сейчас мы участвуем в дальнейшем развитии этого продукта. Вместе с тем были и простые приложения (срок запуска – около двух недель), и масштабные проекты со сроком разработки более года.
3. Безопасность и перспективность
Для бизнеса при выборе языка важно оценить его надежность и безопасность на сегодняшний день с технической точки зрения, а также перспективы дальнейшего развития, риски устаревания.
В вопросе надежности нативная разработка опережает всех своих конкурентов. Развитие основных библиотек идет не один год, в них уже исправили большинство багов, нативные языки – такие, как Java, Objective-C, Swift, Kotlin – постоянно развиваются. Среди мобильных разработчиков можно услышать мнения, что в 2020-х годах нативную разработку на Android частично вытеснит Flutter, но пока это всего лишь предположение.
React Native предоставляет все инструменты для создания безопасных мобильных приложений, пример тому – Skype, Instagram, Facebook и другие известные продукты. Опасения за безопасность возможны только при использовании сторонних модулей при разработке. При этом JavaScript активно развивается, выпускаются новые фичи, в обозримом будущем риск устаревания минимален.
В случае разработки на Flutter риски выше, поскольку фреймворк молодой, релиз вышел только в декабре 2018 года. Пока что бывают проблемы, например, в тот или иной момент сборка библиотек доступна только под одну платформу, случаются сбои в Android Studio, есть баги в некоторых плагинах и библиотеках. С другой стороны, все это дорабатывают и исправляют. Нельзя исключать риск, что Google прекратит поддержку Flutter, как это уже было с другими проектами компании. Однако, на Flutter написана Fuchsia OS, в которой некоторые разработчики видят замену Android.
Для разработчика
Выше мы описали факторы, которые учитывает как бизнес, так и исполнитель. Также имеют место технологические критерии, о которых заботится, в первую очередь, менеджер проекта. Например:
— Уровень знания нативных языков и предпочтения команды
Каждая мобильная студия имеет свои предпочтения в выборе технологий. Нативная разработка требует максимально полного знания соответствующих языков. Однако, благодаря использованию нативных средств систем, меньше ограничений и сложности при кастомизации или осуществлении доступа к платформо-специфичным инструментам (в отличие от React Native и Flutter). При наличии опыта в JavaScript мобильный разработчик может довольно легко перейти на React Native (не нужно дополнительно изучать язык Dart, как в случае с Flutter) или на Dart (большим плюсом будет знание TypeScript).
React Native под капотом задействует нативные модули. Как следствие, если возникает потребность в кастомизации (и это не поддерживается из «коробки»), необходимо работать с модулями native. Например, в нашей практике был случай, когда приходилось кастомизировать библиотеку Яндекс.Карт для вывода кастомных визуальных составляющих на карте.
Flutter, в отличие от React Native, выделяется собственным графическим движком. С одной стороны, это позволяет при разработке простых приложений вообще не касаться native. С другой стороны, при необходимости обращения к native это означает дополнительные сложности (например, обмен сообщениями с элементарными типами данных и JSON) и невозможность использования графических компонентов native.
Если разработчик принимает решение освоить новый язык, важным вопросом становится наличие комьюнити, а также справочной информации и документации.
Flutter и React Native постоянно развиваются, у них есть активное профессиональное сообщество и хорошая документация. При этом нативная разработка опережает фреймворки, благодаря более крупному комьюнити и большему количеству обучающих материалов и форумов, где описаны процессы разработки сложных компонентов.
“Шпаргалка” для выбора
Следующая сравнительная таблица поможет упростить выбор и ответить на вопрос, в каких случаях тот или иной способ реализации подходит (или не подходит) для создания мобильного приложения.
Рекомендации
Если выбор сделан в пользу фреймворков, мы советуем обратить внимание на следующие аспекты работы:
Тестировать нужно все задействованные платформы (iOS, Android). Важно объективно оценить уровень знаний и опыт всех участников проекта, чтобы оценка в часах не оказалась заниженной. Предусмотрите риск появления багов в самих фреймворках React Native и Flutter во время разработки.
Некоторые элементы сложно (или вовсе невозможно) отрисовать в Flutter или React Native. По этой причине дизайн обязательно согласовать с разработчиками – причем до того, как заказчик влюбится в прекрасно отрисованную картинку.
На React Native не исключены специфические проблемы с автосборкой (например, из-за установки библиотек на разные платформы). Нужно заложить больше рискового резерва.
Реализация splash screen на Flutter происходит быстрее, чем на React Native, где этот элемент можно отрисовать лишь нативно, с большой вероятностью возникновения багов. При использовании React Native на splash screen со всеми отрисовками и багофиксами желательно заложить больше времени.
При использовании React Native верстку на iOS и Android нужно проводить одновременно, чтобы в дальнейшем избежать проблем при адаптации верстки под одну из систем.
Параллельная разработка web и mobile
Если веб-версия приложения написана на React, меньше расход времени на разработку мобильного приложения на React Native – за счет одинаковой логики компонентов.
Если приложение большое, на React Native проще провести тестирование и юнит тесты. На Flutter нужно закладывать больше времени на багофикс, поскольку логи не информативны.
Работа приложения с файлами системы
Нужно запрашивать разрешение к sd-card, при этом не с каждым файлом возможно получить имя и путь. Для отправки файла требуется использовать ContentResolver. Для того чтобы минимизировать риски, заложите время на все операции, связанные с файловой системой.
Доставка сборок клиенту
Здесь нет существенных отличий от нативной разработки, можно выбрать любой удобный сервис: Crashlytics, TestFairy, TestFlight.
React Native vs Flutter
Мы в SimbirSoft используем как React Native, так и Flutter, в зависимости от характера приложения. Делимся несколькими наблюдениями из нашей практики, которые помогают предусмотреть особенности работы с тем или иным фреймворком.