Нативное мобильное приложение что это
Что такое «Нативное приложение»?
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 – там, где нет. Всегда с уважением к целевой платформе.
Мобильная разработка: Cross-platform или Native
Всем привет! Я Игорь Веденеев, руководитель мобильной разработки в AGIMA. Поговорим немного о нативной и кроссплатформенной разработке. Раньше я по большей части скептически относился ко второй: не устраивало качество конечных приложений в первую очередь. Однако за последний год темпы развития кроссплатформенных фреймворков уже не в первый раз заставляют пересмотреть свое мнение насчет такого подхода. Поэтому давайте еще раз сравним самые популярные кроссплатформенные решения и нативную разработку.
На всякий случай
Если вы не знаете, что такое нативная и кроссплатформенная разработка:
нативная разработка (2 независимых приложения на языках Swift и Kotlin);
кроссплатформенная разработка — общая кодовая база для iOS и Android (с применением фреймворков Flutter или React Native (далее RN)).
У каждого способа есть свои особенности, плюсы и минусы. Соответственно, под каждый конкретный проект и каждую конкретную цель подходит какой-то один из них. Сейчас объясню, как выбрать и на что обращать внимание.
Нативная разработка
Нативная разработка — это классический способ создания приложения для iOS и Android. Ведется она с использованием инструментов и языков программирования, предложенных вендорами — Apple и Google. Языки в данном случае — Swift (iOS) и Kotlin (Android), а инструментов для профилирования и отладки в нативной разработке очень много.
Однако мы должны понимать, что в данном случае мы делаем два независимых приложения. Разрабатываются они параллельно. Каждое приложение может реализовать фичу по-своему, и у каждого могут быть свои баги. И самое главное, нативная разработка никуда не денется: пока существуют iOS и Android, Apple и Google будут предоставлять инструментарий для создания приложений.
Нативная разработка позволяет создать самое качественное и функциональное приложение, но взамен придется разрабатывать и отлаживать всё 2 раза и следить, чтобы приложения соответствовали друг другу функционально.
Среди разработчиков это пока самый популярный способ создания приложений. Поэтому собрать команду, даже большую, в этом случае проще, чем для кроссплатформы. В первую очередь из-за количества предложений на рынке.
Плюсы и минусы нативной разработки
2 независимых приложения
Стоимость разработки и отладки
Меньше потребляемых ресурсов*
Богатый инструментарий для разработки
Широкий рынок разработчиков
Кроссплатформенная разработка
Кроссплатформенная разработка подразумевает, что мы используем один и тот же код и на iOS, и на Android. Вообще говоря, это всё такое же нативное приложение, но, запустив его, мы сразу проваливаемся в мир Flutter или RN, и всё происходит уже там. Стоит отметить, что разработка на Flutter/RN идет быстрее. Причем не только за счет того, что мы делаем 1 приложение вместо 2-х, а еще и за счет концепций создания приложений, в частности UI.
Но, увы, не всё так хорошо: кроссплатформа имеет ряд проблем, на которые стоит обратить внимание, прежде чем выбирать этот подход для своего приложения. React Native и Flutter всё же сторонние Open Source-решения. В них могут встречаться баги. Новые фишки iOS и Android там будут появляться не так быстро, как при нативных решениях. Может прекратиться поддержка, в конце концов.
Также, довольно часто придется полагаться на сторонние Open Source-библиотеки, что тоже несет в себе риски потенциальных проблем: например, совместимость версии Flutter/RN. Не исключен вариант, что нужной библиотеки не существует в природе, и тогда придется реализовывать всё с нуля самому. Также нельзя добавить расширения для iOS-приложений или, например, приложение на часы. Это касается и Flutter, и RN.
То есть для реализации определенных фич придется добавлять нативный код, что приведет к смешению технологий. Как минимум надо будет иметь в них компетенции. Как максимум — организовывать передачу данных из нативного кода в кроссплатформенный и наоборот.
Если в приложении много логики и есть необходимость сделать ее многопоточной, это тоже будет проблемой и во Flutter, и в RN. Это возможно, но, скажем, это не то, для чего были предназначены эти фреймворки. Также каждый из фреймворков имеет достаточно тяжелую исполнительную среду, что делает кроссплатформенные приложения более ресурсоемкими и требовательными к процессору/оперативке телефона.
Если приложение подразумевает обширное использование аппаратных возможностей телефона, взаимодействия с ОС, то я бы тоже не рекомендовал использовать кроссплатформу — есть риск, что в какой-то момент или код станет очень запутанным, или мы упремся в ограничения одной из платформ или самого фреймворка. Еще стоит учесть, что нам стоит использовать платформенно нейтральный UI, чтобы не создавать потенциальных проблем с различным поведением на платформах и в принципе не снижать на этом скорость разработки.
На картинке ниже представлены результаты теста с простым списком с изображениями: видим, что нативное приложение выигрывает вчистую. Да, на более новых моделях телефонов разница будет не такой значительной, но тенденцию можно видеть. Результаты остальных тестов тут.
Если проще, то кроссплатформа позволяет разработать приложение в кратчайшие сроки. Лучше всего подходит для приложений-витрин услуг или товаров среднего/малого объема без обширного использования платформенных возможностей. То есть снять фотку на аватар или отсканировать QR-код не составит больших проблем, но, если вы делаете приложение вокруг камеры, лучше рассмотреть нативную разработку.
Плюсы и минусы кроссплатформенной разработки
Что выбрать: кроссплатформенная или нативная разработка мобильного приложения
Перед тем, как приступить к созданию мобильного приложения, стоит задуматься о выборе технического подхода к процессу: нативной или кроссплатформенной будет разработка?
В качестве короткого ликбеза поясняем: под нативной разработкой специалисты подразумевают использование оригинальных языков программирования и инструментов мобильной ОС. При кроссплатформенной разработке на вооружение берутся специализированные инструменты, при помощи которых можно создавать приложения, работающие в нескольких мобильных операционных системах сразу.
Оба подхода требуют определённых наборов инструментов, максимально подходящих для написания кода, проектирования интерфейса, отладки, мониторинга всех процессов и сборки окончательной версии приложения.
И оба этих подхода имеют свои преимущества и недостатки как для пользователей, так и для разработчиков. Разобраться начинающим программистам во всех плюсах/минусах нативной и кроссплатформенной разработки помогают специалисты НandsApp.
Михаил Овчинников, (Технический директор студии мобильной разработки Hands App)
Замечательный английский программист Джоел Спольски в своём мега-популярном блоге «Джоэл о программном обеспечении» (Joel on Software) как-то вывел «закон дырявых абстракций». Его суть заключается в следующем: теоретически абстракции должны изолировать нас от более низкого уровня, но в некоторых случаях они всё же настолько сложны, что нужно вникать в особенности реализации и на низком уровне.
Этот принцип относится и к кроссплатформенным фреймворкам. Обычно они абстрагируют разработчиков от особенностей написания кода под отдельную платформу. Однако, как только вопрос касается производительности или реализации специфического функционала под платформу, так сэкономленное при разработке время съедается на решении этих проблем.
Разумеется, есть области, где применение кроссплатформенных технологий полностью оправдано. Прежде всего разработка игр: к примеру, движок Unity — это хороший вариант для большинства разработчиков. Многие маркетологи, имея лишь базовые знания HTML/CSS/JS, успешно используют Ionic для тестирования своих гипотез без привлечения отдела разработки. Многие стартапы выбирают Flutter для того, чтобы быстро сделать минимально жизнеспособную версию продукта (MVP), доказав тем самым на практике конкурентоспособность своего детища.
Не нужно забывать и о том, что подходы при разработке приложения можно комбинировать. Например, отрабатывать критичные к производительности экраны (лента новостей в социальной сети) на нативных технологиях, а второстепенные (экран профиля, экран настроек) — на кроссплатформенных.
Если смотреть с точки зрения карьерного старта программиста, то делать ставку на кроссплатформенную разработку довольно рискованно: у крупных компаний пока мало вакансий такого рода, и вряд ли эта ситуация сильно изменится в будущем. У крупных компаний уже написаны огромные кодовые базы на нативных технологиях, которые нужно кому-то поддерживать. Поэтому если есть мечта — работать в одном из ИТ-гигантов, — то лучше выбрать ту платформу, которая больше нравится и заняться её углубленным изучением.
Никита Красавин, …(ведущий iOS разработчик студии мобильной разработки Hands App)
Давайте для начала разберёмся в деталях: что такое нативная разработка, что из себя представляет кроссплатформа, и чем они отличаются.
Нативная разработка — это процесс воплощения мобильного приложения с использованием официальных средств, предоставляемых разработчиками системы, для которой пишется приложение. Она направлена на одну конкретную мобильную систему. Например, Apple предоставляет интегрированную среду разработки XCode для нативной разработки приложений под iOS. И нельзя написать с помощью XCode приложение для Android. Всё очень просто: один код — одна система.
Кроссплатформенная разработка — это способ создания приложения с возможностью адаптации под несколько систем. По аналогии: один код — много систем.
Несмотря на то, что кроссплатформенные средства позволяют сильно экономить время, нативная разработка в среде программистов более популярна. По нескольким причинам, давайте рассмотрим основные.
1. У мобильных систем iOS и Android есть существенные различия, которые вызывают сложности при кроссплатформенной разработке. Это касается в первую очередь элементов интерфейса. Именно поэтому написать один универсальный код иногда гораздо сложнее, чем сделать это нативно.
2. Нативные среды максимально оптимизированы для работы со своей системой. Кроссплатформенным инструментам же приходится проксировать вызовы системных методов. В результате падают показатели быстродействия, и поэтому кроссплатформенные приложения чаще крашатся, дольше думают и тормозят.
3. Поддерживать кроссплатформенный код гораздо сложнее, чем нативный. Обновление систем приводит к частому обновлению программных интерфейсов, что требует больше рабочего времени программиста (если сравнивать с работой по обновлению кода нативного приложения).
4. При разработке нативного приложения программист почти всегда находит ответ на интересующий его вопрос по коду от коллег или использет сторонние библиотеки для конкретной задачи. В кроссплатформенном мире комьюнити меньше: часто приходится решать возникшую проблему самостоятельно. Собственно этот пункт относится к сфере популяризации нативной разработки: чем больше сторонников — тем больше комьюнити. А значит и работа над конкретной задачей упрощается.
Таким образом, преимущество скорости кроссплатформенной разработки нивелируется рядом прочих негативных факторов.
Подведём итоги: кроссплатформа удобна при написании простого приложения, в котором мало экранов и много общих элементов для разных платформ. Идеальная задача для кроссплатформы — разработка мобильной игры.
Для приложений с уникальными интерфейсами и сложной бизнес-логикой больше подходит нативный способ разработки.
Программистам-новичкам однозначно лучше начинать с нативной разработки хотя бы потому, что большое комьюнити всегда поможет сориентироваться в возникшей проблеме и даст наводку на ту информацию, которая поможет в каждом конкретном случае.
Руководитель направления маркетинга в студии мобильной разработки Hands App
Судя по «обильным» комментариям ваш материал явно не для VC 🙂
Но, вам «повезло», что вы «нарвались» на коллегу по цеху, который может предположить, что у вас еще мало опыта использования фреймворков в мобильной разработке, чтобы писать такие статьи.
Но, причем тут: «Многие стартапы выбирают Flutter для того, чтобы быстро сделать минимально жизнеспособную версию продукта (MVP), доказав тем самым на практике конкурентоспособность своего детища.» или «Поддерживать кроссплатформенный код гораздо сложнее, чем нативный.»
Многие стартапы хотят использовать Flutter, но стоимость работы специалистов Flutter/Dart им не по карману, и они вынуждены довольствоваться тем, что могут себе позволить: Ionic, Cordova, Xamarin.
Flutter – это лучшее, что появилось в мобильной разработке за все время ее существования! Ко всему, может случиться так, что это будет единственно подходящий инструмент для разработки приложений под новую Fuchsia (операционная система, разрабатываемая компанией Google, взамен Android).
Если у вашей студии есть возможность разработать более-менее серьезное приложение для iOS и Android платформ в нативе, а затем, перевести на Flutter, далее, сравнить скорость работы интерфейсов, то вы сразу поймете, почему Flutter – это действительно «новая эра» в разработке визуальных частей мобильного приложения!
Например, на Android устройствах нативный код работает через Java-машину и поэтому интерфейсы тормозят, а Flutter работает напрямую с операционной системой и ее графическим ускорителем – все интерфейсы просто летают!
Нативное мобильное приложение что это
Что такое нативная и кроссплатформенная мобильная разработка, чем они отличаются, как сделать выбор. Объясняет 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.