Что такое нативное программное обеспечение

Обновлено: 18.05.2024

  • Нативные приложения (англ. native application) — это прикладные программы, которые были разработаны для использования на определённой платформе или на определённом устройстве.

Одно из преимуществ нативных приложений — то, что они оптимизированы под конкретные операционные системы, поэтому они могут работать корректно и быстро.

Также они имеют доступ к аппаратной части устройств, то есть могут использовать в своём функционале камеру смартфона, микрофон, акселерометр, геолокацию, адресную книгу, плеер и т.д.

Связанные понятия

Разработка приложений для мобильных устройств — это процесс, при котором приложения разрабатываются для небольших портативных устройств, таких, как КПК, смартфоны или сотовые телефоны. Эти приложения могут быть предустановлены на устройство в процессе производства, загружены пользователем с помощью различных платформ для распространения ПО или являться веб-приложениями, которые обрабатываются на стороне клиента (JavaScript) или сервера.

Дра́йвер (англ. driver, мн. ч. дра́йверы) — компьютерное программное обеспечение, с помощью которого другое программное обеспечение (операционная система) получает доступ к аппаратному обеспечению некоторого устройства. Обычно с операционными системами поставляются драйверы для ключевых компонентов аппаратного обеспечения, без которых система не сможет работать. Однако для некоторых устройств (таких, как видеокарта или принтер) могут потребоваться специальные драйверы, обычно предоставляемые производителем.

Платформа для корпоративных мобильных приложений (англ. Mobile Enterprise Application Platform, сокр. MEAP) обеспечивает клиент-серверную среду исполнения и инструменты для разработки корпоративных мобильных приложений, обладающих высокой адаптивностью к различным типам устройств и имеющимся на них операционным системам, поддерживающих автономный режим работы.

Мультимедиастанция (также медиастанция) — электронное устройство, универсальный проигрыватель, позволяющий просматривать и/или прослушивать мультимедиа, не прибегая к помощи персонального компьютера, используя телевизор и/или AV-ресивер. Может входить в состав домашнего кинотеатра.

О типе данных в БД см. BLOB.Блоб (от англ. binary linked object — объект двоичной компоновки) — объектный файл без публично доступных исходных кодов, загружаемый в ядро операционной системы. Обычно этот термин применяется только по отношению к модулям, загружаемым в ядро свободной или открытой операционной системы; термин редко применяется по отношению к коду, выполняющемуся не в режиме ядра, например, код BIOS, микропрограммный код устройств, программы, выполняющиеся в пользовательском режиме.

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

Текстовый пользовательский интерфейс, ТПИ (англ. Text user interface, TUI; также Character User Interface, CUI) — разновидность интерфейса пользователя, использующая при вводе-выводе и представлении информации исключительно набор буквенно-цифровых символов и символов псевдографики. Характеризуется малой требовательностью к ресурсам аппаратуры ввода-вывода (в частности, памяти) и высокой скоростью отображения информации. Появился на одном из начальных этапов развития вычислительной техники, при развитии.

Адаптер программного компонента — это тип программного обеспечения, которое логически располагается между двумя программными компонентами и устраняет различия между ними.

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

Насыщенное интернет-приложение (англ. rich internet application, RIA) — это веб-приложение, загружаемое пользователем через интернет, предназначенное для выполнения функций традиционных настольных приложений и работающее на устройстве пользователя (не на сервере).

Мобильный сайт — сайт, расположенный в сети либо на локальном носителе по определённому адресу (домену), созданный для просмотра на мобильных устройствах, чаще всего для просмотра с помощью мобильного браузера.

Мобильное устройство (то есть легко перемещаемое, портативное) — это любое небольшое устройство, которое обычно содержит дисплей и миниатюрную клавиатуру (позже был изобретён сенсорный экран с виртуальной клавиатурой). Первоначально это были в основном карманные устройства, но разнообразие таких устройств постоянно увеличивается. Устройства становятся более гибкими и могут выполнять различные функции, такие как запись и воспроизведение мультимедиа, подключение к видеочатам, подключение к Интернету.

Рутинг (англ. Rooting) — процесс получения прав суперпользователя root на устройствах под управлением операционной системы Android. Основными целями рутинга являются снятие ограничений производителя либо оператора связи, манипулирование системными приложениями и возможность запуска приложений, требующих прав администратора. Устройство, прошедшее процесс рутинга, называется рутованным. Аналогичный процесс для устройств на базе Apple iOS называется Jailbreak, а для устройств на базе Windows Phone.

Веб-устройство (англ. Web-device или Web-устройство, или устаревший термин: англ. Internet appliance) — цифровое устройство (не только компьютер), имеющее возможность быть постоянно подключенным к сети интернет и используемое для взаимодействия с какими-либо веб-службами. Большинство современных веб-устройств предоставляют удобный способ запуска веб-приложений и веб-серфинга (просмотра веб-сайтов и веб-страниц во всемирной паутине).

Установка программного обеспечения, инсталляция — процесс установки программного обеспечения на компьютер конечного пользователя. Выполняется особой программой (пакетным менеджером), присутствующей в операционной системе (например, RPM, APT или dpkg в Linux, Установщик Windows в Microsoft Windows), или же входящим в состав самого программного обеспечения средством установки. В операционной системе GNU очень распространено использование системы GNU toolchain и её аналогов для компиляции программного.

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

Вебтоп — интерфейс рабочего стола, встроенного в браузер или подобное приложение-клиент. Вебтоп объединяет в себе веб-приложения, веб-сервисы, клиент-серверные приложения, серверы приложений. Вебтоп представляет собой рабочий стол, похожий на Windows, Mac, или графический интерфейс на системах Linux или Unix, работающий внутри браузера как обычный веб-сайт. Внутри него, приложения, данные, файлы и настройки сохраняются на сервере и при необходимости передаются в вебтоп. Браузер, в таком случае, в.

Тест-пойнт (англ. test points — ключевые точки) — точка на электронном оборудовании, дающая доступ к программному обеспечению в случае программной или аппаратной ошибки. В частности, тест-пойнты, расположенные на плате мобильного телефона, позволяют записывать в загрузочную область какую-либо информацию .

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

Экранное считывающее устройство — это один из видов вспомогательных технологий (вт), предназначенных для слепых людей, имеющих плохое зрение а также людей имеющих затруднения при обучении. Считывающие устройства это такие программные обеспечения, с помощью которых, их пользователи могут постигать визуальную информацию без использования зрения, например озвучивания, звуковые значки или Брайлевского дисплея.В операционных системах Windows, начиная с версии Windows 2000, встроено экранное считывающее.

Сетевая плата (в англоязычной среде NIC — англ. network interface controller/card), также известная как сетевая карта, сетевой адаптер (в терминологии компании Intel), Ethernet-адаптер — по названию технологии — дополнительное устройство, позволяющее компьютеру взаимодействовать с другими устройствами сети. В настоящее время в персональных компьютерах и ноутбуках контроллер и компоненты, выполняющие функции сетевой платы, довольно часто интегрированы в материнские платы для удобства, в том числе.

Компью́терный термина́л, оконе́чное устро́йство — устройство, используемое для взаимодействия пользователя (или оператора) с компьютером или компьютерной системой, локальной или удалённой. Могут содержать в себе клавиатуру, дисплей, печатающее устройство, различные виды манипуляторов, устройства для подачи звуковых сигналов (простейший динамик), дисковый или ленточный накопитель. Выводимая терминалом информация может быть как текстовой, так и графической.

Сервер приложений (англ. application server) — это программная платформа (фреймворк), предназначенная для эффективного исполнения процедур (программ, скриптов), на которых построены приложения. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (интерфейс прикладного программирования), определённый самой платформой.

Аппаратное шифрование — процесс шифрования, производимый при помощи специализированных вычислительных устройств.

Се́рверное програ́ммное обеспечение (се́рвер, англ. server от to serve — служить; множественное число се́рверы, в разговорном языке также употребляется сервера́) — в информационных технологиях — программный компонент вычислительной системы, выполняющий сервисные (обслуживающие) функции по запросу клиента, предоставляя ему доступ к определённым ресурсам или услугам.

Компьютерная телефония (CTI, англ. Computer Telephony Integration) — технологии, обеспечивающие взаимодействие компьютеров и традиционных телефонных сетей. Компьютерная телефония позволяет объединить передачу речи с передачей цифровых данных, а также обеспечить отслеживание вызовов и управление ими по любому сценарию (голос, электронная почта, веб-интерфейс, факс и т. д.). Компьютерная телефония используется, в частности, при создании центров телефонного обслуживания и вместо офисных АТС. Существуют.

Управление мобильными устройствами (англ. Mobile device management, MDM) — набор сервисов и технологий, обеспечивающих контроль и защиту мобильных устройств, используемых организацией и её сотрудниками.

Аппаратная платформа компьютера (архитектура компьютера) — уровень, образованный микроархитектурой, микропрограммой управления ядром микропроцессора и архитектурой набора команд на аппаратной базе конкретных микросхем процессора, чипсета, других физических компонентов, которые в совокупности составляют аппаратную модель вычислительной системы.

Консо́ль (англ. console — пульт управления) — совокупность устройств (в том числе устройств ввода-вывода), обеспечивающая взаимодействие человека-оператора с компьютером.

Софтфо́н (калька с англ. software telephone, программный телефон) — класс программного обеспечения для персонального компьютера для совершения телефонных (голосовых) или видеозвонков через Интернет (в общем случае через любую IP-сеть) без использования дополнительного аппаратного обеспечения, за исключением гарнитуры, USB-телефона, микрофона и аудиоколонок, вебкамеры (в случае видеосвязи).

Моби́льная игра́ — игровая программа для мобильных устройств, например сотовых телефонов, смартфонов, коммуникаторов, КПК и прочих (за исключением ноутбуков).

Планшетный персональный компьютер (планшетный ПК, tablet PC) — полноразмерный IBM PC-совместимый ноутбук (персональный компьютер), оборудованный сенсорным экраном, позволяющий работать при помощи стилуса или пальцев, как с использованием, так и без использования клавиатуры и мыши.

Виртуализа́ция — предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе.

Аппаратная виртуализация — виртуализация с поддержкой специальной процессорной архитектуры. В отличие от программной виртуализации, с помощью данной техники возможно использование изолированных гостевых систем, управляемых гипервизором напрямую.

Токен (также аппаратный токен, USB-ключ, криптографический токен) — компактное устройство, предназначенное для обеспечения информационной безопасности пользователя, также используется для идентификации его владельца, безопасного удалённого доступа к информационным ресурсам и т. д. Как правило, это физическое устройство, используемое для упрощения аутентификации. Также этот термин может относиться и к программным токенам, которые выдаются пользователю после успешной авторизации и являются ключом для.

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

Веб-компоненты — технология, которая позволяет создавать многократно используемые компоненты в веб-документах и веб-приложениях. Веб-компоненты поддерживаются веб-браузерами напрямую и не требуют дополнительных библиотек для работы.

Мультизагрузка (англ. Multi-boot) это техническая возможность выбора, при включении компьютера, операционной системы для запуска. Для настройки такой возможности может потребоваться специальный загрузчик операционной системы и разбиение диска на несколько разделов.

Принт-сервер (англ. print server — сервер печати) — программное обеспечение или устройство, позволяющее группе пользователей проводных и беспроводных сетей совместно использовать принтер дома или в офисе.

Одностраничное приложение (англ. single page application, SPA) — это веб-приложение или веб-сайт, использующий единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML, CSS, JavaScript, обычно посредством AJAX.

Виртуализация сетевых функций (англ. Network Functions Virtualization, NFV) — это концепция сетевой архитектуры, предлагающая использовать технологии виртуализации для виртуализации целых классов функций сетевых узлов в виде составных элементов, которые могут быть соединены вместе или связаны в цепочку для создания телекоммуникационных услуг (сервисов). Концепция виртуализации сетевых функций была предложена в 2012 году Европейским институтом телекоммуникационных стандартов (ETSI).

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

Особенности разработки нативных приложений

Что это вообще такое?

Нативное приложение делают отдельно под каждую платформу. Если вы хотите иметь нативные приложения для iOS и Android, нужно разрабатывать два отдельных приложения на разных языках, например, для iOS Swift, а для Android — Kotlin.

Что хорошего в нативе?

Гибкий, богатый функционал. В приложении можно реализовать любые возможности, поддерживаемые телефоном.

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

Именно поэтому Pokemon GO сделали нативным. Приложение должно было использовать встроенные системные возможности без задержек.

Отличная скорость работы приложения. При разработке используется родной для платформы код, и у готового приложение получается быстрый отклик и отзывчивый интерфейс. По сравнению с таким же по функционалу и качеству кода кроссплатформенным приложением, нативное быстрее на 30%.

Для 50% пользователей производительность приложений ОЧЕНЬ важна. Источник: medium.com

Быстрое обновление. Если функционал iOS и Android обновляется, сразу же обновляются и нативные приложения. С кроссплатформенным приложением придется ждать обновления фреймворка. И никто не скажет, на сколько это затянется.

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

Для приложений, чей UI/UX основан на стандартных паттернах пользователей, это может быть критичным.


Особенности кроссплатформенной разработки

Что такое кроссплатформа?

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

Что хорошего в кроссплатформенной разработке?

Стоит меньше и делается быстрее. Кроссплатформенная разработка, как правило, экономит ресурсы, поскольку код пишется одновременно для iOS и Android. Экономия составляет до 50% времени.


На Flutter, например, писать код быстрее, чем на натив. И, соответственно, дешевле.

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

Единый UI. Логика работы у iOS и Android разная, поэтому нативные приложения в них выглядят по-разному. Кроссплатформенное приложение одинаково на всех платформах.

Меньше ошибок в бизнес-логике. Кроссплатформенные приложения пишут кроссплатформенные разработчики, которые пользуются единой основой для iOS- и Android-версии.

Широкая аудитория. Кроссплатформенные приложения доступны пользователям iOS и Android, поэтому аудитория изначально шире. С другой стороны, с кроссплатформой до аудитории можно и вовсе не добраться: у AppStore, например, очень жесткие требования к гибридным приложениям и они с большим трудом проходят модерацию в маркете.

Примеры кроссплатформенных решений. Источник: litslink.com

Самые неприятные ограничения кроссплатформенных фреймворков

Дело вот в чем: верстка для кроссплатформы делается по той же технологии, что и для адаптивных сайтов, а при переносе макетов в код нативных приложений соблюдается сетка iOS и Android. Сетки у iOS и Android разные, плюс у них разные размеры и форматы иконок для экрана приложения. Именно поэтому нативная интеграция лучше отображается на разных мобильных устройствах. Даже если это один из тысяч смартфонов на Android и модель с нестандартным экраном. У нестандартного экрана все равно будет стандартная сетка, так что макет со стандартизированными колонками нормально интегрируется в приложении. Кроссплатформенная верстка на нестандартный экран может не встать ни на Андроиде, ни на iOS. Отсюда и баги, которые крайне сложно находить и устранять. У нас был случай, когда в приложении отображалась ошибка с нажатием одной из кнопок. Ошибка воспроизводилась только на одной модели Xiaomi Redmi Note. Мы тестировали приложение на пяти других моделях Xiaomi, искали ошибку на симуляторах, но проблема не воспроизводилась. Пришлось купить именно ту модель Xiaomi Redmi Note, на которой не срабатывала кнопка, и только тогда мы отыскали причину бага.

Реальная задача на fl.ru

Рано или поздно наступает момент, когда каждая правка такого приложения превращается в ад, муки и дорогие часы техподдержки.

Кто помнит, несколько лет назад на рынке мобильных приложений случился бум недорогих коробочных решений за 300-500 тыс. рублей. Их много сделали для сервисов доставки еды и такси. Приложения работали на кроссе и первое время баги редактировались командой разработки. Через пару лет исправление багов стало настолько трудозатратным и дорогим, что разработчики отказались от поддержки, а владельцы бизнеса остались у разбитого корыта. Старые приложения копили баги и работали из рук вон плохо. Чтобы перевести клиентов на новые, нужно было провести масштабную работу с аудиторией. И не факт, что получилось бы.

Привередливость операционных систем. У платформ множество различий и все их нужно учитывать в кроссплатформенном фрейме. Например, macOS управляет оперативной памятью, а Windows — нет.

Чтобы приложение не только бесперебойно работало, но и полноценно использовало системные функции, нужен хороший, очень хороший кроссплатформенный разработчик, а их на рынке немного.

Apple предпочитает нативный код. В политике Apple кроссплатформенные решения не в почете: иногда компания выпускает запрещающий список кроссплатформ, которые больше не смогут публиковаться в App Store.

Сложная оптимизация. Чтобы код работал как часы, его нужно оптимизировать. А в кроссплатформенном фреймворке это сделать непросто: базовые структуры платформ слишком разные. Одно из временных решений — кодировать исходное приложение в многоплатформенной среде, а затем экспортировать приложение в собственной код и уточнить. И здесь сходит на нет и экономия времени, и экономия денег.

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

Этот список меняется каждый год и здесь только 10 моделей из тысяч

Как выбрать платформу разработки

Отталкивайтесь от задач, которые поставлены перед проектом. Нативное приложение — единственный вариант для узкой или исключительно требовательной платежеспособной аудитории. Для технически простых проектов, рассчитанных на широкую аудиторию или B2B приложений для корпоративного использования можно выбрать кроссплатформу.

Если приложению нужна максимальная производительность, предусмотрена многоступенчатая вложенность, требуется предельная отзывчивость, максимум системных функций — это только натив. Также, только в нативном приложении можно реализовать сложные интерфейсы. Вот почему игровые продукты с 3D графикой могут быть только нативными.

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

Что такое нативная и кроссплатформенная мобильная разработка, чем они отличаются, как сделать выбор. Объясняет Surf.


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

Натив и кроссплатформа: что это вообще такое

Это два типа разработки. Нативное приложение создаётся для конкретной операционной системы на языке программирования, который ей понятен. Пишутся два отдельных кода для двух ОС.

В случае кроссплатформы программисты используют фреймворки — программные каркасы, на которые затем вешают необходимые функции. Фреймворки универсальные — с их помощью создают приложения сразу для нескольких ОС. Код один, а систем много.

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

Натив: что это, кому подходит, примеры

Программирование в нативной среде ведётся на нескольких языках. Для Android это Kotlin и Java, а для iOS — Swift и Objective-C.

Нативная разработка — мощный инструмент. Подходит для тех, у кого мобильное приложение — основной канал продаж, и большой бюджет на развитие.

Плюсы нативного подхода

Система лучше понимает свой язык. С приложением, написанным специально под iOS или Android, будет меньше технических сложностей, в том числе с обновлениями. Его проще оптимизировать, сделать быстрее или легче. А чем меньше весит приложение, тем охотнее его скачивают пользователи.

Никаких ограничений: можно смело браться за реализацию любых идей, связанных с работой устройства — камерой, GPS, сенсорами, файловой системой устройства и так далее.

В нативной разработке намного больше специалистов — нет проблем с тем, чтобы найти сотрудников на проект или просто с кем-то посоветоваться.

Нативные приложения хороши всем, кроме стоимости. Это дорогой проект: для каждой ОС придётся разрабатывать свою логику, интерфейс и вёрстку. Под каждую платформу нужно держать отдельный штат разработчиков и тестировщиков. В зависимости от региона зарплата опытного мобильного разработчика начинается от 90 000 рублей, а у старшего специалиста может достигать 350 000 рублей.


Зарплаты мобильных разработчиков — одни из самых высоких на рынке. Данные Хабр Карьеры за второе полугодие 2020

Итог: нативное приложение оптимально для конкретной операционной системы, меньше весит, быстрее работает и даёт все возможности для реализации сложных функций. Но будьте готовы к большим расходам.


Кроссплатформа: что это, кому подходит, примеры

На рынке представлено много кроссплатформ: 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.

Эти приложения называют нативными оттого, что они написаны на родном (с англ. native – родной) для определённой платформы языке программирования. Для Android этим языком является Java, тогда как для iOS – objective-С или Swift.

Нативные приложения находятся на самом устройстве, доступ к которым можно получить, нажав на иконку. Они устанавливаются через магазин приложений (Play Market на Android, App Store на iOS и др.).

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

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

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

  • скорость работы и производительность;
  • высокая степень безопасности;
  • расширенный интерфейс;
  • относительно высокая стоимость разработки;
  • максимально возможная функциональность;
  • способность работать без Интернета;
  • удобство для конечного пользователя.
  • охват платформ;
  • длительные сроки разработки;
  • необходимость выпускать обновление в косметических целях.

Примеры нативных приложений:

Первый пример – приложение Shazam, осуществляющее определение и поиск информации об играющей на другом устройстве песне:

  • устанавливается из магазина приложений;
  • для работы необходим доступ в Интернет;
  • использует диктофон телефона.

Второй пример – приложение Instagram:

  • устанавливается из магазина приложений;
  • для работы также необходим доступ в Интернет;
  • использует ПО смартфона: камера, геолокация, адресная книга;
  • можно включить получение push-уведомлений.

Мобильные веб-приложения

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

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

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

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

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

Примеры мобильных веб-приложений:

    считается веб-приложением, хотя, по сути, это в то же время и веб-сайт. – веб-сайт, но в то же время это и веб-приложение.

Гибридные приложения

Гибридные приложения представляют собой сочетание веб и нативных приложений. В особенности, имеется в виду их кроссплатформенность и доступ к функционалу смартфона. Такие приложения могут быть загружены исключительно из маркетов вроде Google Play и App Store. Вместе с тем они располагают опцией автономного обновления информации, а для их работы необходимо интернет-подключение. Без наличия последнего веб-функции попросту не работают.

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

Разработка гибридного приложения видится перспективной ещё и потому, что она подразумевает создание его сразу под две платформы. Как следствие, это лишает головной боли, связанной с отдельной разработкой приложения под каждую ОС. Решающий ли это фактор? Безусловно.

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

Итак, стоит разрабатывать его, если:

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

Примеры гибридных приложений:

Первый пример – приложение HeartCamera для iOS, позволяющее украсить фотографию рисованными сердцами и т.п.

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

Второй пример – приложение TripCase – органайзер для планирования путешествий.

Если вы уже приняли решение о необходимости создания мобильного приложения, один из следующих этапов - определиться, какой тип приложения выбрать.

Эра смартфонов

Если человек уже принял решение о необходимости создания мобильного приложения, один из следующих этапов — определиться, какой тип приложения выбрать. Будет ли это нативное приложение? Или лучше выбрать веб-приложение? Что такое гибридное приложение, и почему его предлагают? Если Вам не понятно, о чем это я, то эта статья для вас. Если понятно, то вы сможете систематизировать свои знания или укрепиться в своем правильном выборе. И, при желании, написать мне о своем мнении или задать вопросы.

Итак, из этой статьи Вы узнаете:

Какие бывают мобильные приложения;

Какие преимущества Вы получаете при выборе определенного типа приложений;

Какие существуют ограничения у разных типов приложений;

Какое приложение подойдет именно вам в конкретной ситуации.

Нативные приложения

Первый пример — приложение Shazam, осуществляющее определение и поиск информации об играющей на другом устройстве песне (в App Store, в Google Play):

  • Устанавливается из магазина приложений;
  • Для работы необходим доступ в интернет;
  • Использует диктофон телефона.



Второй пример — не менее известное приложение Instagram (описание и ссылки для скачивания в магазинах):

  • Устанавливается из магазина приложений;
  • Для работы также необходим доступ в интернет;
  • Использует ПО смартфона: камера, геолокация, адресная книга; Можно включить получение push-уведомлений.



Веб-приложения, или приложения на html5

Веб-приложения не случайно называют html5-приложениями. Это, по сути, сайт, оптимизированный под смартфон. Пользовательский интерфейс создается при помощи стандартных веб-технологий. Их не нужно загружать из магазина приложений, но они могут находиться в специальных магазинах веб-приложений, которые есть у некоторых современных браузерах, например у Chrome. Веб-приложения используют для работы браузер телефона. Главной особенностью таких приложений является их кроссппатформенность — возможность работать на всех устройствах, без дополнительной адаптации.

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

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


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

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


Здесь осталось только заметить, что не все веб-приложения оптимизированы под мобильные телефоны. Что, конечно, не может быть нашим случаем.

Гибридные приложения

Примеры гибридных приложений:

1. Приложение HeartCamera для iOS, позволяющее украсить фотографию рисованными сердцами и т.п.

  • Загружается из магазина;
  • Использует камеру телефона;
  • Необходимо подключение к интернету при желании поделиться результатом своей работы;
  • Можно настроить push-уведомления.



2. Приложение TripCase — органайзер для планирования путешествий. (Ссылки для скачивания в магазинах доступны на сайте )

  • Загружается из магазина;
  • Может использовать геолокацию;
  • Необходимо подключение к интернету;
  • Может использовать сотовую сеть;
  • Можно настроить push-уведомления



Таблица преимуществ и недостатков

Нативное

Максимальная функциональность и скорость работы

Не требуется интернет- соединение для использования

Имеет доступ к ПО смартфона (GPS, плеер, камера) Распространение через магазины приложений

Выше стоимость и длиннее сроки разработки

Требует от разработчика знаний определенной среды программирования

Работает только с одной платформой

При косметических изменениях необходимо выпускать обновление

Веб (HTML5)

Не требует загрузки из магазина мобильных приложений

Можно легко адаптировать обычный сайт

Легче найти веб-разработчика нежели разработчика под определенную платформу Простота создания и поддержки

Требует подключения к интернету

Не имеет доступа к ПО смартфона

Не может отправлять push-уведомления

Должен быть запущен интернет-браузер

При продаже требуется использование своей платежной системы

Гибридное

Функциональность нативного приложения на независимой платформе

Запускается не из браузера в отличии от веб приложения Возможность независимого обновления

Распространение через магазины приложений

Загружается из магазина мобильных приложений (необходимо соответствовать требованиям)

Разработчик должен быть знаком с разными API

Как определиться с выбором

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

Подведем итоги

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

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


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

Однако позволю себе немного дополнить каждый из подходов, остановившись немного поподробнее на деталях.

Нативные приложения.

Во-первых, не всегда сроки разработки больше, чем при создании html5 или гибридных приложений: всё зависит от его сложности и архитектуры. Если вам требуется сделать какие-то выезжающие меню или интересную анимацию — это нередко проще и быстрее реализовать с помощью нативных компонентов, нежели писать аналогичный функционал с нуля на html5/css/javascript. Конечно, можно попробовать воспользоваться готовыми библиотеками, но это не всегда возможно.

Во-вторых, оптимизация под различные размеры экранов (смартфоны и планшеты). При использовании нативных компонентов ОС это может быть выполнено в достаточно короткие сроки, и приложение получится интереснее и функциональнее, нежели в случае web-приложений. Примеров подобного рода можно привести достаточно много. Возьмите хотя бы стандартное приложение Gmail под Android и запустите его на смартфоне, а затем на планшете.

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

Веб-приложения.

Здесь хочется отметить, что веб-приложениями нередко называют и мобильные приложения, которые написаны с помощью html/css/javascript , и устанавливаются на устройство пользователя через официальные магазины (App Store, Google Play и т.д.). Обычно это реализуется следующим образом: вначале весь контент и интерфейс пишутся при помощи веб-технологий. В результате получается определённый набор связанных между собой html-страниц, которые можно перенести без изменений на любую платформу. Затем, в среде разработки (xcode, eclpise и т.д.) создаётся простое приложение, которое архитектурно состоит из одного экрана со встроенным браузером, через который и показываются написанные страницы. Таким образом, получается как бы нативное приложение, распространяемое через маркеты, однако, по сути, написанное при помощи веб-технологий.

Некоторые разработчики поступают ещё хитрее: чтобы не выпускать обновления, они просто зашивают в браузер ссылку на внешнюю страницу и при запуске приложения показывается оптимизированная версия сайта.

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

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

Поэтому с подобными приложениями надо быть очень аккуратными.

Гибридные приложения.

Как верно отметил автор статьи, гибридный вариант является некоторой серединой между нативными и web-решениями. Данный подход позволяет создать часть (а иногда и все) компонентов кроссплатформенными, и при этом получить доступ к различным возможностям устройства, сохранив хорошую скорость работы. Однако здесь всё зависит от того, каким инструментом будут пользоваться разработчики.

В настоящее время наиболее известными и популярными фреймворками для разработки подобных решений являются PhoneGap и Xamarin.

Первый из них автор как раз и описала в соответствующем разделе своей статьи. PhoneGap — это html/css/javascript фреймворк, с помощью которого пишется приложение. Доступ к функциям устройства осуществляется посредством использования javascript API фреймворка, а весь контент создаётся на html и css. Приведённые примеры приложений My Heart Camera и TripCase как раз были разработаны при помощи PhoneGap. Основным достоинством данного подхода является полная кроссплатформенность создаваемого кода, поскольку используются всё те же веб-технологии.

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

Если выбирать между веб-приложением и гибридным решением — лучше остановиться на последнем, поскольку оно позволяет сделать всё то же самое за схожие сроки, только оставляет более широкое пространство для дальнейшего развития.

Из недостатков Xamarin можно выделить следующее:

  • время разработки не сильно меньше нативной;
  • не всегда просто удаётся подключить сторонние нативные библиотеки;
  • долгий процесс сборки проектов, что сказывается на общем времени разработки;
  • различные ошибки фреймворка, которые, однако, постепенно исправляются.

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

Если вы хотите получить хорошее приложение с расширяемым функционалом — используйте нативный подход, или же фреймворки, аналогичные Xamarin.


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

В нативных приложениях такой проблемы нет. Декомпиляция (получение исходных кодов) это довольно трудоемкий и порой очень длинный процесс, поэтому тут нативные приложения одерживают победу.

Если оценивать по критерию безопасности гибридные приложения, то они удачно совмещают высокую безопасность и простоту разработки. Но есть небольшой нюанс, который относится и к HTML5-приложениям. При таком многообразии версий браузеров в различных версиях iOS и Android безупречную работу HTML5 и гибридных можно гарантировать не на каждом из устройств, так как некоторые функции могут отсутствовать в ранних версиях браузеров.


Посудите сами: написание приложений под мобильные платформы в ней сводится к написанию всего лишь двух блоков: 1) платформонезависимого (бизнес-слой, слой данных, слой логики и 2) платформозависимого (Application UI Layout). Причем платформонезависимый блок составляет 90% приложения, который единовременно используется на всех платформах. Остается всего лишь написать Application UI Layout для каждой мобильной платформы. Что же мы получаем на выходе? Сокращение в несколько раз времени, затрачиваемого на разработку кроссплатформенных приложений, а следовательно, и стоимости. Не в этом ли заключается мечта заказчика и разработчика?

Читайте также: