Нативные технологии что это
Нативная и кроссплатформенная разработка: как сделать правильный выбор в 2021
Просто и понятно о том, в каком случае можно использовать кроссплатформенную разработку, а когда не обойтись без нативной.
Я знаю, что это далеко не первый текст на данную тему. Но до сих пор в топовых позициях находятся статьи с устаревшей и неверной информацией (например, что кроссплатформенные приложения нельзя опубликовать в магазинах). Поэтому я решил актуализировать информацию и рассказать об отличиях в подходах в простой форме, для тех, кто однажды столкнётся с разработкой мобильных приложений.
Представим себе Сергея, у которого есть автопарк. Сергей хочет получать больше заказов и поэтому решается на разработку собственного приложения для вызова такси. Разумеется, он хочет охватить больше клиентов: поэтому ему нужно программное обеспечение как для IOS, так и для Android. Сергей понимает, что это будет два разных приложения, но что-то слышал о том, что можно сделать одно, которое будет работать на всех смартфонах.
Теперь Сергей знает, что есть что. На первый взгляд, кроссплатформенная разработка кажется более выгодной, но он понимает, что в подходах есть существенные различия.
Логично было бы предположить, что кроссплатформенная разработка должна стоить в два раза меньше, чем нативная, ведь разрабатывается одно приложение вместо двух. Но это не так и вот почему. Несмотря на то, что при кроссплатформенной разработке у продукта будет одинаковая бизнес-логика и навигация, экраны для каждой системы будут отличаться. Таким образом, для IOS и Android отрисовываются и реализуются собственные экраны приложения. Если говорить о цене, то стоимость кроссплатформенной разработки в среднем на 70% ниже, чем нативная.
Нативное приложение всегда будет выглядеть лучше, чем то, что разработали по мультиплатформенной технологии. Дизайн, скорость загрузки, доступ ко всем функциям устройства (камера, геолокация, календарь и так далее), интерфейс – все это будет давать нативной разработке сто очков вперед. Кроссплатформенные приложения в этом плане уступают нативным – работают медленнее, а интерфейс значительно отличается.
Нативная разработка дороже, так как придется задействовать как минимум двух разработчиков, специализирующихся на разных платформах. Кроме того, такой подход требует больше времени.
Главным достоинством кроссплатформенного подхода является то, что скорость разработки выше, нежели у нативной, а времени и ресурсов затрачивается меньше.
Наш Сергей немного запутался, попробуем до бавит ь конкретики .
Кроссплатформенная разработка не подходит для серьезных бизнес-проектов. Такое решение оптимально при написании простого приложения, в котором мало экранов и много общих элементов для разных платформ. Например, данный тип разработки выгоден при написании прототипа приложения под несколько платформ в сжатые сроки, для игрового или тестового приложения.
Для приложений с уникальными интерфейсами и сложной бизнес-логикой больше подходит нативный способ разработки.
Теперь Сергею понятно, зачем нужна кроссплатформенная и нативная разработка, он принял решение для своего проекта, но все равно еще все обсудит с профессионалами.
Нативная разработка на нескольких платформах выгоднее для веб-студий, но мы в Yusmp Group не навязываем такие услуги проекту, которому это не требуется. Если заказчику нужна демонстрационная версия, а сроки и бюджет ограничены, то разумнее выбирать кроссплатформенную разработку.
Технология создания мобильных приложений: нативная или кроссплатформенная разработка
Что такое нативная и кроссплатформенная разработка
Под нативной разработкой (от английского native – родной) подразумевается использование оригинальных языков и инструментов разработки мобильной операционной системы.
Разработка приложений под ios происходит в среде разработки XCode на языке Swift (а раньше – на Objective-C).
При использовании технологии разработки мобильных приложений на платформе андроид используется среда Android Studio и язык Kotlin (до 2018 года основным языком был Java).
Каждая среда разработки содержит целый комплекс утилит для написания кода, проектирования интерфейса, отладки, профилирования (мониторинга) и сборки приложений. И среда, и соответствующий набор утилит созданы специально под каждую мобильную операционную систему, и являются максимально удобными и мощными средствами разработки мобильных приложений.
Кроссплатформенная технология разработки мобильного приложения подразумевает использование специальных фреймворков для создания приложения на основе семейства языков JavaScript. Вся структура и логика приложения создается с помощью таких инструментов (React Native, Flutter, Ionic, Xamarin, PhoneGap и др.) на JavaScript, а затем оборачивается в нативный запускающий элемент, т.е. интегрируется в базовый проект для XCode или Android Studio. Это позволяет создавать сборки проекта с одной и той же логикой под несколько операционных систем сразу.
Простая аналогия просматривается в случае с персональными компьютерами: MS Word, Skype, почтовые агенты, календари – это нативно разработанные приложения под настольную операционную систему. Всё, что происходит в браузере (сайты, онлайн-редакторы текста и графики, социальные сети, чаты, форумы) – кроссплатформенные технологии.
Логотипы Xcode и Android Studio
Плюсы нативной технологии разработки мобильных приложений
Разработка мобильного приложения в Москве на родных технологиях и языках под iOS и Android имеет следующие положительные моменты:
1. Скорость работы приложения
Так как приложение создается с использованием оригинальных инструментов разработки (Xcode, Android Studio), получаемый в результате компиляции проекта код является оптимальным для данной платформы.
Приложение получает полную аппаратную поддержку устройства (обработка тех же изображений осуществляется отдельным процессором, специально для этого предназначенным – GPU), используется многопоточность для реализации сложных задач и загрузки контента в фоне.
В процессе разработки программисты могут измерять скорость работы всех участков кода и при необходимости их оптимизировать. В их распоряжении также есть инструменты по мониторингу использования оперативной памяти, поиску возможных утечек и т.д.
2. Гибкость в реализации
В отличие от ограничений в построении интерфейса и сложности визуальных эффектов, накладываемых фреймворками для кроссплатформенной сборки проектов, в нативной технологии разработки мобильных приложений реализовать можно все, на что способны технологии той или иной мобильной операционной системы.
3. Использование последних технологий и зависимость от кроссплатформенных фреймворков
Новый программный и аппаратный функционал, предоставленный компаниями-производителями устройства и операционной системы, становится доступен для реализации сразу после выпуска соответствующих обновлений.
К примеру, в iOS 9 заложена возможность поиска внутри приложений. В каждом из них должен быть реализован специальный метод, который возвращает результаты по определенному поисковому запросу. В результате для тех нативных iOS приложений, в которых этот функционал реализован, доступна возможность поиска контента через системный раздел поиска в iOS. Там же, где осуществляется поиск приложений, контактов, событий и прочей информации.
В случае с кроссплатформенной технологией разработки мобильных приложений, для реализации подобного функционала придется ждать не только релиза iOS 9, но и обновления соответствующего фреймворка, причем когда появится поддержка тех или иных новых возможностей и появится ли вообще, предсказать невозможно.
4. Легкость и качество тестирования
Помимо упомянутого в п. 1 инструментария для контроля использования приложением аппаратных ресурсов устройства, в распоряжении разработчиков и тестировщиков есть целых комплекс технологий.
Во-первых, все параметры системы в процессе работы приложения контролируются автоматически. Если приложение стало использовать больше памяти, чем это ожидается, или больше ресурсов центрального процессора, это не останется незамеченным.
Во-вторых, возможности в широком применении юнит-тестов – автоматического тестирования практически каждого метода в приложении. Если какая-то часть приложения перестала работать корректно вследствие каких-либо изменений кода, новая версия просто не соберется, а программист сразу увидит причину.
В-третьих, доступны широкие возможности в интеграции систем удаленного мониторинга ошибок. В каждый нативный проект встраивается соответствующий функционал, который позволяет увидеть ошибку и ее причину, возникшую на устройстве любого пользователя.
5. Полная поддержка со стороны магазинов приложений App Store и Google Play
Обе компании заинтересованы, чтобы пользователи получали максимально положительный опыт при использовании приложений на соответствующих платформах, который возможен на текущий момент.
Это означает, что приложение должно выглядеть максимально качественно (если у экрана высокое разрешение, а изображения расплывчаты, в App Store приложение просто не пропустят), работать настолько быстро, насколько это возможно (если приложение отображает небольшой список элементов за 20-30 секунд, его так же не пропустят), и вообще все должно быть красиво и удобно.
Если какие-то из этих параметров слишком низки или вообще не выполнены, приложение не пропустят в магазин. Если же они не на высоте, чего добиться с кроссплатформенными технологиями создания мобильных приложений крайне сложно, а часто и невозможно в принципе, ваше приложение никогда не будет рассмотрено соответствующими компаниями для размещения в специальных рекламных разделах (Featured).
Среди приложений, находящихся во Featured-разделах и App Store, и Google Play, нет ни одного, сделанного с помощью кроссплатформенных технологий. За исключением игровых проектов, в которых интерфейс не является системным.
Плюсы кроссплатформенной технологии разработки мобильных приложений
Кроссплатформенная среда разработки имеет следующие положительные моменты:
Яркий пример – кнопка “Назад” в навигации между экранами. В Android предусмотрена аппаратная кнопка Back для этих целей. У iOS – движение пальцем от левой части экрана или же наличие кнопки в левой части навигационной панели. Если кнопку не делать вовсе, пользователи iOS не смогут вернуться назад. Если сделать, но не на том месте и выглядящую нестандартно, пользователям iOS будет непривычно и неудобно; а если сделать как в iOS, будет непривычно пользователям Android.
Однако написанная и отлаженная один раз логика содержит потенциально меньшее количество ошибок и расхождений в своей работе. Поэтому вам не придется проделывать двойную и тройную работу по поиску проблем на каждой платформе.
Выводы
С технической точки зрения и с точки зрения качества создаваемого интерфейса нативная технология разработки мобильных приложений имеет гораздо больше плюсов. Однако есть сферы, в которых кроссплатформенные технологии являются оправданными: это игровой сектор и тестовые проекты.
Современные игры пишутся в подавляющем большинстве на кроссплатформенных технологиях. Это сильно ускоряет разработку без ущерба для качества, т.к. в этом случае используются специальные графические фреймворки (самый популярный – Unity 3D).
Если какой-то проект нужно сделать быстро для проведения каких-либо тестов, при этом ситуация требует работы проекта именно на нескольких платформах одновременно, кроссплатформенная реализация может быть оптимальным решением.
Если проект не является игровым, направлен на долгосрочное развитие и требует положительного впечатления от пользователей, то рациональнее будет создать мобильное приложение нативным способом. После того как способ разработки выбран, время обсудить стоимость разработки приложения.
Почему не надо оформлять патент на идею мобильного приложения
Многие начинающие предприниматели первым делом ищут возможности получить патент на свою идею. В этой статье мы тезисно перечислим причины этого не делать.
Свяжитесь с нами
Хотите получить бесплатную консультацию о разработке мобильного приложения?
Мы сможем сразу дать ориентировочную оценку проекта по стоимости и срокам, если Вы кратко опишите его основную идею и функции.
Заполните заявку или позвоните нам
Тоже интересно
Приложение с программой лояльности
Создание игр для мобильных устройств на Android, IOS
10 вопросов, которые помогут понять, нужно ли вам мобильное приложение
Тренды разработки мобильных приложений в 2022
Контакты
Компания
Написать нам
Соцсети
Copyright © 2011-2020, AppCraft LLC
Мы используем куки, чтобы
сделать мир прекраснее
Спасибо!
Мы скоро с вами свяжемся и подробно проконсультируем по интересующим вас вопросам.
А пока можете узнать подробнее о том, как формируется стоимость, сколько времени занимает реализация проекта и о других нюансах разработки в наших статьях.
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
CEO компании по разработке ИТ-решений FriFlex
В мире более пяти миллиардов смартфонов. Из них около 85% работают на Android, остальные 15% — на iOS, по данным IDC. Казалось бы, выгоднее разработать нативное приложение для Android? Но не все так однозначно, и всегда жаль терять одну из аудиторий.
Чтобы оптимизировать процесс и не программировать мобильное приложение для каждой из операционных систем, можно прибегнуть к кроссплатформенной разработке. В ее основе лежит единый исходный код и стек технологий.
Петр Чернышев, CEO Friflex, компании, которая специализируется на разработке кроссплатформенных приложений, объясняет, что эти технологии дают бизнесу и почему лучше выбирать Flutter.
Содержание:
Что такое кроссплатформенная и нативная разработка?
Рассмотрим три основных варианта разработки приложений.
PWA — это технология, которая трансформирует веб-сайт в мобильное приложение. PWA позволяет открывать приложение с помощью мобильного браузера.
Нативная разработка позволяет создавать приложения только для одной ОС — отдельно для iOS, Android и других. Разработка осуществляется строго на нативном языке программирования ОС. К примеру, в iOS применяются языки Swift/Objective-C, в Android — Java/Kotlin. При выборе нативной разработки придется поддерживать минимум две платформы раздельно. Нативное приложение будет работать только на «своей» платформе. Один код — одна ОС.
Кроссплатформенная разработка, ее также называют мультиплатформенной. В этом случае используется единая кодовая база, которая подойдет для разных платформ, будь то Android, iOS, Windows, macOS, Linux. Технология может применяться даже в умных часах или для программирования бытовой техники.
Различия кроссплатформенной и нативной разработки
Нативная разработка однозначно проигрывает мультиплатформенной с точки зрения финансовых затрат. Ведь для нее нужно практически задвоить все процессы. Разные логика предметной области, кодовая база и технологический стек ведут к:
Когда стоит применять мультиплатформенную разработку?
У кроссплатформенных фреймворков нет ограничений для реализации функций в мобильном приложении. И есть и объективные причины для использования кросс-платформенной разработки:
Но есть и случаи, когда нативная разработка может оказаться предпочтительнее. Однако это не означает, что применение нативной разработки всегда менее целесообразно. В некоторых ситуациях стоит выбрать именно ее:
Лучшие кроссплатформенные фреймворки для приложений
Разберем четыре самые популярные кроссплатформенные технологии и выделим их особенности.
Разработан Facebook для поддержки таких платформ, как iOS, macOS, Apple tvOS, Android, Android TV, Web, Windows и UWP. Технология дает возможность работать с библиотекой React вне браузера для создания нативных приложений, имеющих полный доступ к системным API-платформам.
Позволяет использовать единый исходный код для логики предметной области приложений Android и iOS. Специфичный для платформы код потребуется только в определенных моментах (при работе со специфичными для платформы API или для разработки собственного пользовательского интерфейса).
Фреймворк разработан Google и постоянно обновляется. При том, что технология использует один код для двух ОС, для конечного пользователя приложение не отличается от нативного. Таким образом, Flutter совмещает в себе преимущества кроссплатформенного и нативного подходов, что уже оценили многие крупные компании. Свой выбор в пользу данной технологии сделали Alibaba, Philips Hue, Hamilton, Tencent, Grab, Groupon, ГК «Дикси», «Яндекс.Драйв» и другие мировые и российские компании.
Сравнительная таблица кроссплатформенных фреймворков, по данным на январь 2021
Команда Friflex успела поработать и оценить все фреймворки. Опираясь на богатый опыт, мы выбрали Flutter, который постоянно развивается и предлагает новые функции и разработчику, и бизнесу.
Google активно работает над фреймворком и постоянно его обновляет: в марте 2021 года компания представила обновленную версию Flutter 2. Согласно исследованию Statista, в 2020 году Flutter использовали 39% мировых девелоперов, в 2021 показатель составил 42%, сместив React Native на второе место. Такой рост популярности обусловлен высокой скоростью написания кода.
Опрос на портале Stackoverflow показал, что Flutter входит в тройку любимых фреймворков разработчиков. Пользователи GitHub (крупнейшего сервиса для хранения исходного кода) также положительно оценили Flutter. На данный момент у фреймворка уже 128 тыс. звезд.
Данные сайта insights.stackoverflow.com
Преимущества кроссплатформенной разработки приложений
К преимуществам кроссплатформенной разработки относят скорость разработки (она выше) и стоимость разработки (она ниже). Расскажем о преимуществах на примере фреймворка Flutter:
Google Trends подтверждает растущий интерес к фреймворку Flutter, это видно из сравнительного графика ниже.
Данные сайта trends.google.ru
Flutter используется разработчиками по всему миру. А благодаря сокращению времени разработки кода, увеличению скорости вывода продукта на рынок, производительности, близкой к нативной, и другим преимуществам, нет сомнений, что Flutter будет развиваться и доминировать на рынке в ближайшем десятилетии.
Нативная разработка, 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, в зависимости от характера приложения. Делимся несколькими наблюдениями из нашей практики, которые помогают предусмотреть особенности работы с тем или иным фреймворком.