Эволюция в вашем кармане: как развивались мобильные приложения

WAP и первое подключение к интернету

WAP (Wireless Application Protocol) появился в 1998 году, и именно он объединил интернет и мобильную связь. Теперь можно было встроить в телефон браузер, установить соединение с серверами и получить данные на устройство.

Одним из первых телефоном с WAP-браузером был Nokia 7100, который выпустили в 1999 году. Тогда же начали появляться компании, разрабатывающие продукты специально для мобильных устройств.

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

WAP-версия сайта Билайна

В то время компании еще не оценили телефоны как способ коммуникации с клиентами, поэтому таких решений было катастрофически мало.

Например, Ericsson сделали путеводитель Michelin: через WAP была доступна база из 60 000 отелей и ресторанов Европы. Еще несколько примеров использования WAP для бизнеса приведены в White Paper Nokia 1999 года:

• Клиенты Deutsche Bank и Visa International могли получать информацию о последних транзакциях, просматривать баланс и оплачивать счета;
• Пассажиры авиакомпании Finnair могли бронировать билеты и получать информацию о рейсах.

Первая открытая ОС для разработчиков

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

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

Без сертификата приложение не запускалось вообще или сильно страдало в функционале

В это же время развивался рынок Java-приложений. Разработка приложения на Java занимала меньше времени и подходила для Windows Mobilе, Android, bada, Palm OS и BlackBerry OS. В Symbian также поддерживалось подмножество Java — J2ME, но функциональность таких приложений была сильно ограничена, поэтому разработкой на Java под Symbian практически никто не занимался.

В Nokia никак не стремились помогать разработчикам развивать рынок. Все было настолько плохо, что в 2005 году вышла Symbian 9.1, которая была не совместима с приложениями, выпущенными для предыдущих версий. Каждое приложение требовало доработки.

У разработчиков не было нормальной среды для создания проектов, большинство использовали Eclipse, предназначенной изначально для разработки на Java. Nokia выпустили инструмент для разработки на C++ — Carbide на основе Eclipse, но большая часть его возможностей была платной. Лицензия стоила от 300 до 8000 евро, это сильно влияло на конечную стоимость приложения.

При этом развитием самой Symbian никто особо не занимался, больше внимания уделяли новым дизайнам смартфонов Nokia. На рынок выходили новые модели, а саму ОС обновляли примерно раз в год.

Попытки что-то исправить в Nokia начали предпринимать только в 2009 году. Они пытались решить проблемы с недружелюбным API, дать больше возможностей для создания приложений и упростить разработку с помощью фреймворка Qt, затем открыли исходный код Symbian и объявили о создании Symbian Foundation, что должно было помочь популяризировать ОС.

Но это все не помогло собрать вокруг Symbian сообщество разработчиков и партнеров-производителей смартфонов. В итоге ОС не смогла конкурировать с iOS и Android.

Выход iPhone и запуск App Store

В 2007 году Стив Джобс представил миру первый iPhone. Тогда много говорили о возможностях нового смартфона, но никто не говорил, как этих возможностей удалось достичь.

Архитектура iOS была похожа на MacOS, но система была полностью закрытой. Джобс не хотел, чтобы сторонние разработчики могли разрабатывать приложения для iOS, и не собирался открывать SDK. Вместо этого он хотел, чтобы разработчики создавали веб-приложения, и дал возможность создавать браузерные закладки на домашнем экране. Мы знаем это из биографии Джобса, которую написал Уолтер Айзексон.

Полноценный движок Safari уже присутствует внутри iPhone. То есть вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете что? Для этого не нужен SDK!, — Стив Джобс.

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

Позже совет директоров Apple все же убедил Джобса легализовать сторонние приложения. В итоге в марте 2008 года iPhone SDK стал доступен всем желающим, а в июле презентовали App Store. Это означало, что Apple берет на себя дистрибуцию продуктов разработки пользователям.

Стив Джобс презентует AppStore и систему монетизации для разработчиков

App Store стал толчком к развитию индустрии разработки приложений, но проблемой был Objective-C. Язык программирования для iOS кардинально отличался от популярных тогда скриптовых JavaScript и Flash Action Script. Мало кто хотел тратить время на изучение нового синтаксиса, ведь устройства на iOS занимали еще очень маленькую долю рынка, а основная его часть принадлежала смартфонам на Symbian.

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

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

Проблемы кроссплатформенности: когда всем надо все и сразу

В 2008 появился Android Market, а в 2010 — Windows Mobile Store.

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

Быстрое параллельное развитие iOS и Android создало двухполярную систему, и разработчикам нужно было поддерживать несколько платформ одновременно. Из кроссплатформенных инструментов были только Flash и обычный мобильный браузер. И то в 2010 году Apple отказались от поддержки технологии Adobe Flash в iOS.

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

Как все решилось

На помощь пришли библиотеки компонентов и фреймворки для создания приложений на Android и iOS на базе браузерных технологий без использования языков программирования: Xamarin, Cordova, Phonegap.

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

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

Развитие кроссплатформенных решений: React Native

В 2015 году разработчики Facebook на конференции React.js Conf представили свой инструмент для кроссплатформенных решений — фреймворк React Native. В нем компоненты приложения, написанные на JS, транслируются в нативные Android и iOS. Этот инструмент принципиально отличается от других систем для создания кроссплатформенных приложений:

• Отсутствием WebView и HTML-технологий;
• Отрисовкой интерфейса. В RN её выполняет ОС устройства, а не браузер;
• Отсутствием дополнительной «обертки» кода — вместо нее JS взаимодействует с ОС через специальный мост. Так в приложении используются нативные компоненты пользовательского интерфейса.

Благодаря этим отличиям приложения, сделанные на React Native, максимально похожи на нативную разработку, и у них меньше проблем с производительностью.

Хотя стало проще и лучше, проблемы все равно остались:

• Знаний одного JS все равно не хватит, потому что работу с возможностями мобильной платформы нужно реализовывать через модули на нативных языках;
• Facebook постоянно что-то переписывает в архитектуре RN, поэтому вечно что-то меняется. Новые релизы часто сопровождаются обратной несовместимостью в коде;
• Скорость работы приложений выше, но все еще не на уровне нативных приложений;
• Нативная разработка становится проще.

Производители стараются минимизировать сложности в разработке и пытаются упростить языки разработки. В результате появились более простые Swift и Kotlin.

Swift представили на конференции WWDC в 2014 году. В нем осталось много от Objective-C, но он работает по аналогии со скриптовыми языками. Код определяется типами переменных, а не указателями. Это делает его изучение легче для тех, кто уже владеет каким-либо скриптовым языком.

Kotlin с 2010 года разрабатывала компания JetBrains. Целью было сделать более лаконичный и простой язык, чем Java, в котором уже накопился багаж неудачных решений. С 2017 язык официально рекомендуется для Android-приложений.

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

Сравнение Swift и Kotlin

Получилось упрощение не только от Objective-C к Swift и от Java к Kotlin, но и от Swift к Kotlin и наоборот. Это гораздо больший шаг к кроссплатформенности, чем разработка приложений на web-view.

Что происходит прямо сейчас

Мобайл — основной канал коммуникации

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

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

Заказать карту можно только через приложение

Противостояние Native vs Web-view

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

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

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

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

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

Сценарий взаимодействия пользователя и приложения. Если пользователю нужно постоянно пользоваться приложением, важны отзывчивость и нативный интерфейс.

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

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

Нужен ли доступ к сервисам устройства. В нативном приложении проще реализовать доступ к камере, микрофону или геолокации. Средствами Web-view это тоже возможно, но тогда придется искать возможность оптимизировать нагрузку на процессор. Кстати, это не всегда возможно, в Web-view нет готовых оптимизированных компонентов и приходится каждый раз что-то изобретать. Сначала для того, чтобы что-то работало, а потом — чтобы это что-то не «съедало» батарею смартфона.

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

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

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

Наличие API для бэкенда. Если API есть, это уже шаг в сторону нативки. Необходимость делать API увеличивает цену и срок нативной разработки, для Web-view его разрабатывать не нужно. Но тут снова нужно отталкиваться от задач и планов на этот проект. Чтобы развивать приложение в дальнейшем, лучше выделить деньги и время на API.

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

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

Разработчикам стоит исходить из задач, потребностей и возможностей бизнеса, и использовать те или иные технологии, когда это оправдано. Не привязываться к «трушности» методов, а миксовать все с учетом ограничений так, чтобы приложение помогало бизнесу взаимодействовать с пользователем, а не ограничивало коммуникацию.