Со стороны iOS разработка может казаться закрытым клубом. Для работы обязательно нужен Mac, Apple пристально контролирует экосистему. Изнутри тоже иногда слышны противоречия — кто-то говорит, что язык Objective-C старый и неповоротливый, а кто-то, что новый язык Swift слишком сырой. 

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

В этот раз о своем опыте нам рассказали Марат Нургалиев и Борис Павлов — как они учились профессии IOS-разработчика, как проходили первые собеседования, почему получали отказы. А экспертом выступил Андрей Антропов — декан факультета iOS-разработки в GeekBrains.

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

Тем не менее, ему не отказали, а дали практическое задание — за две недели реализовать отображение списка новостей с помощью API. И под iOS, и под Android. «Если на Android у меня был какой-то опыт, то для создания iOS версии не было даже инструмента. Среда разработки ios приложений есть только на Mac. Но через две недели я вернулся, показал, что мог на Android. С iOS пришлось выкручиваться на ходу. В итоге меня взяли. Тогда я жил в Астрахани. Меня устраивала любая работа в ИТ с зарплатой выше двадцати».

Кто такие — iOS-разработчики

IOS-developers - это мобильные разработчики делают приложения для любых портативных устройств. Смартфоны, планшеты, умные часы и все остальные платформы, которые поддерживают Android или iOS. Фундаментальные основы мобильной разработки не отличается от обычной, но из-за специфических инструментов ее выделили в отдельное направление. Здесь используются свои инструменты, языки программирования и фреймворки. 

«Для работы с iOS нужен макбук, потому что только на нем есть необходимая среда разработки Xcode. Она бесплатна и распространяется через магазин приложений AppStore. Для установки надо иметь своей Apple ID и больше ничего. В Xcode можно разработать приложения для чего угодно — телефона, планшета, часов. Встроенный симулятор и редактор есть для всего», — говорит Андрей Антропов, декан факультета iOS разработки в GeekBrains.

«Но среду разработки можно поставить и на Windows, если использовать „Хакинтош”. Это рабочий, но окольный вариант — никто из серьезных разработчиков подобным не занимается. Начинающие покупают старенький Макбук. А опытные обычно могут себе позволить последнюю модель».

Языки — Swift или Objective-C

Почти вся iOS-разработка ведется при помощи языка программирования Swift. Он появился пять лет назад и сейчас постепенно вытесняет старый язык Objective-C, который Apple использовала во всех своих приложениях больше 30 лет

«На Objective-C накоплена огромная база кода, поэтому до сих пор требуются разработчики на оба языка, в зависимости от компании, от ее задач и приложений. Приложения, написанные много лет назад, основаны на Objective-C. А все новые проекты по умолчанию разрабатываются на Swift. Сейчас Apple очень много делает для того, чтобы вести одновременную разработку под телефон, планшет, часы и Макбук было максимально удобно. Один и тот же код может быть скомпилирован и запущен везде. Раньше этого не было. Под iOS разрабатывали на Swift, под MacOS использовали Objective-C».

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

«Objective-C достаточно старый язык — ровесник языка С++. Во времена, когда его разрабатывали, требования к языкам были совсем другими. Когда появился Swift, в нем было много багов, функциональность была ограниченной, синтаксис был шероховатым. А на Objective-C у людей была набита рука. Он много лет совершенствовался, все ошибки там были исправлены. Но теперь, я думаю, Swift не уступает Objective-C. Хотя даже Apple в своих проектах до сих пор использует оба. Языки во многом взаимозаменяемые и взаимно дополняемые. Структуры и объекты одного языка можно превратить в объекты и структуры другого языка. Хорошо бы знать оба варианта, но для новичков Objective-C часто кажется пугающим и непонятным».

Обучение IOS-разработке

«На моей первой работе меня обучал начальник, помогал в реализации и настройке проекта», — рассказывает Марат, —  «Но работать по Android и по iOS одновременно трудно. Нужно время для перестройки, переключения с проекта на проект, с языка на язык. В итоге я решил, что нужно выбрать одно направление и изучать его. Меня подкупили интерфейс Xcode и простой синтаксис Swift».

Марат поступил на факультет iOS-разработки в GeekBrains. Первое время было очень легко, потому что многие вещи он знал по опыту работы. Годовой курс разбит на четыре четверти. По словам Андрея, в первой дается только самая база: «Основа языка Swift, знание базовых фреймворков, сетевое взаимодействие, хранение данных, жизненный цикл приложения, контроллера, базовые архитектуры, основные библиотеки, которые все используют, многопоточность и параллелизм в приложениях».

Во второй четверти добавляется Objective-C. Проводится курс по архитектуре, базовым паттернам программирования. В третьей четверти учат правильному стилю написания кода. Рассказывается, что такое фабрика, как правильно писать тесты, формировать проекты, что такое Git-Flow, Continuous Integration через Fast Lane. Четвертая и завершающая четверть посвящена командной работе, практическим заданиям и стажировкам.

«Первая четверть прошла легко», — говорит Марат, — «но потом началось изучение программирования на Objective-C, изучение паттернов проектирования, принципов Solid, Git-Flow, архитектуры проекта, Unit и UI тестирования приложений, настройка кастомной анимации — и тогда мне стало интересно учиться». 

«У меня в GeekBrains все началось не супер гладко», — рассказывает Борис Павлов, и его путь к iOS-разработке в целом был не самым прямым. Парня воспитывала бабушка. Она была архитектором, математиком и дизайнером и привила Борису любовь к проектированию, научила чертить от руки и рисовать. Его дядя был сисадмином и заинтересовал племянника компьютерами. 

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

Он начал изучать C++ с преподавателем в Иркутском Институте Солнечно-Земной Физики. Затем заинтересовался геймдевом и попробовал перейти на C#. И, наконец, как и Марата, его подкупил язык Swift. 

«Я решил пройти бесплатный вводный курс в GeekBrains. Если честно, он был очень скучным, вялым и непонятным», — вспоминает Борис, — «преподаватель рассказывал об особенностях языка, но метался из одной темы в другую не раскрывая сути. Когда курс закончился, я так ничего и не понял».

Поэтому после вводного курса Борис поступил не на годовое обучение, а на короткий трехмесячный курс, где преподают самые основы профессии. «Там мне попались очень хорошие преподаватели, и объясняли все достаточно понятно».

«Нас часто критикуют, якобы у нас не совсем актуальные методички, есть неточности. Но курсы постоянно обновляются, а преподаватели всегда рассказывают о новшествах. Из групп, которые я веду, очень многие трудоустраиваются уже после первой четверти. Конечно, обычно это люди с опытом программирования», — говорит Андрей, —  «С другой стороны, все знания невозможно донести за один курс. Сетевое клиентское взаимодействие в жизни не уместишь в десять лекций по два часа. И если ты ходишь только на курсы IOS-разработки и больше ничего дополнительно не делаешь, то знаний не хватит. Если же весь год заниматься каждый день, то при таком темпе только ленивый не устроится. Потому что спрос в профессии очень большой».

Вакансии сюда

Вы можете посмотреть самые свежие вакансии для iOS-разработчиков и подписаться на новые.

Работа

Но ни у Марата, ни у Бориса трудоустройство не прошло так просто. 

«Некоторые крупные фирмы давно разработали iOS приложения на Objective-C, и  продолжают поддерживать старую кодовую базу. К сожалению, у меня нет весомого аргумента, чтобы заставить их использовать исключительно Swift. Особенно тех, кто пользуется правилом „не трогай то, что работает“», — говорит Марат, — «Направлению Objective-C в Geekbrains уделяется мало внимания. Оно несет скорее ознакомительный характер. Но каждая компания, в которую я собеседовался, спрашивала про Objective-C. А так как учеба ориентирована на Swift, как и моя прошлая работа, то на собеседованиях я получал отказы».

«После учебы я самостоятельно знал только самые поверхностные основы, с помощью которых мог создать самое простое приложение», — рассказывает Борис, — «Для работы, конечно же, было недостаточно, но я радовался и этому. С поисками работы в Иркутске было сложно. Если точнее — совсем никак. Я решил искать в других городах. По количеству вакансий самыми актуальными оказались Краснодар, Москва и Петербург. Я решил поехать в СПБ — ближе к Европе. 

Но все оказалось не так радужно. Даже от джуниора IOS-разработки простят того, чего он знать не может. Я пока не нашел работу. Работаю за „спасибо“, набираюсь опыта. Понимаю, что это не то, чего я хотел, но мне интересно, и это движет мной. Я хочу получать знания».

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

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

Зарплаты

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

«Джуниор совсем низко уровня часто работает бесплатно или за символические деньги — 20–30 тысяч рублей. Если же джуниор целенаправленно взят на свою позицию, то получит от 50 до 80 тысяч. Мидлы получают от 100 до 150, и иногда даже до 200. Синьоры в IOS-разработке меньше 200 не получают. Я думаю, их зарплата в районе 200–300. А у тимлидов, соответственно, за 300».

Зарплаты сюда

По данным калькулятора зарплат «Моего круга» средняя зарплата iOS-разработчика составляет немногим меньше 140 000 рублей.

Собеседования

«Первое собеседование прошло по скайпу. На мое удивление это был Google», вспоминает Борис, — «тогда я только переехал в Питер и начал искать работу. Мне пришел отклик на вакансию iOS разработчика. Не джуниор, не мидл, не синьор — просто разработчик. Я обрадовался, начал переписываться с менеджером. Меня попросили выполнить техническое задание: надо было написать приложение для шуток про Чака Норриса. Я его написал. Мне сказали, что все классно и назначили онлайн собеседование.

Мы созвонились. Со мной общалась приятная девушка. Но никаких вопросов про знание языка не задавали — только разные логические задачки, например, „Время 15:15 сколько градусов между часовой и минутной стрелкой?“ или „Столб 10 метров, улитка днем ползет 3 метра вверх, ночью спускается на 1 метр. Через сколько дней она доползет до верха?“, и еще парочка подобных. 

Потом были совсем странные вопросы — за что я люблю Apple и как отношусь к Тиму Куку. Я сказал, что к компании в целом — положительно, а к нему скорее отрицательно, потому что ему важны деньги, а не продукты. 

Когда начались вопросы про Swift, моих знаний хватило только на паттерны программирования и основы ООП. Мы распрощались, через неделю мне перезвонили и сказали, что я не подхожу. Собственно, я из этого извлек огромный опыт: нужны знания, их нужно много — и теория, и практика».

Андрей рассказывает, что «первая вещь, которую у всех спрашивают на собеседовании — это жизненный цикл контроллера. Очень любят спрашивать какой-нибудь простенький паттерн программирования. Обязательно спросят про опыт использования популярных библиотек. Точно будет вопрос про отличия в Swift Value Types от Reference Types, про Automatic Reference Counting и управление памятью. Могут спросить, как реализовывали хранение данных в приложениях, и реализовывали ли сетевые запросы. Спросят про основы REST и JSON. Специфические вещи и тонкости у джуниора не будут спрашивать. По крайней мере я не спрашиваю».

У Бориса же был иной опыт: «Даже когда я просился на стажировки, выполнял технические задания и говорил, что мне не важна зарплата, лишь бы ее хватало на съем квартиры — мне все равно отказывали. Я читал статьи, пытался понять, что нужно рекрутеру от новичка. Но заваливали в основном на теории. Почему-то задавали вопросы из высшей лиги, которые не касаются новичков». 

Марату повезло больше. Сейчас он работает в транспортной компании и один отвечает за iOS направление, продолжая учебу на факультете. «Поскольку за iOS отвечаю я один, мой труд оценивается только умением реализовать поставленные передо мной задачи [а не знанием теории]».

Сообщество

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

«Мировое комьюнити обычно общается через твиттер. Люди ведут свои блоги, записывают ролики на Youtube, зовут друг друга на подкасты. Однажды у меня появился вопрос по презентации, где выступал тимлид HQTrivia. Это американская викторина, в которую играет одновременно несколько миллионов человек. Я ему написал в твиттере, он мне ответил, мы пообщались, я поблагодарил. Комьюнити чрезвычайно дружелюбные, и это здорово».

Литература

https://docs.google.com/document/d/1-cMseCx1vBwVA8xv4uccpE_vkqvhPG_1Wt9gLiLWAGQ/edit#

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

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

Ресурсы

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

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

Сложность

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

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

Стимулирование

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

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

Ошибки

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

Разумеется, главную свою задачу приложение должно выполнять на 100 процентов. Если уже при первом запуске выявится заметный баг, можете быть уверены — пользователя вы потеряли.

Не нативная реклама

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

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

Косность функционала

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

Неряшливый дизайн

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

Скорость

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

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

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

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

Правило 1. «Как корабль назовешь...»

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

• Тренды и известные личности. Законы большого интернета работают и в мобильных маркетах. Упомянув громкое событие или известную личность, можно попытаться урвать часть славы. Яркий пример — Томас Суарез, 12-летний мальчишка, создавший игру Bustin Jeiber и выступивший на конференции TED. Само приложение не выдающегося качества, но имя певца (искаженное во избежание бана) принесло ему сотни тысяч скачиваний.
• Слава популярного приложения или игры. История успеха Дмитрия Быстрова наглядно демонстрирует, как громкое название вкупе с качественным исполнением может принести 130 тысяч скачиваний.
• Оптимизация для поисковых систем и зрительного сканирования. Если вы откроете топ любого магазина приложений, увидите там примерно такие заголовки:

Их общая черта — ясное представление о том, что скрывается внутри. Такая однозначность идеально подходит для поиска.

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

Правило 2. Есть всего 3 предложения

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

Устали носить с собой ручку и записную книжку? С новым приложением «Блокнот» вам больше это не потребуется. Делайте сколько угодно записей любого объема, сохраняйте в удобном формате и быстро находите заметки с помощью функции «Поиск».

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

Правило 3. Слова имеют ценность

Все, что следует за первыми тремя предложениями, не должно быть бессмысленным описанием. Если следовать предыдущим двум пунктам, к этому моменту пользователь уже «на крючке». Так что теперь требуется привести множество «обезвоженных» аргументов, почему ваше приложение лучшее. Помогут три классических приема:

1. Списки. Люди их любят за то, что можно опустить большую часть текста, просматривая лишь тезисы.
2. Цифры. Даже если статистические данные не демонстрируют превосходство над конкурентами, они все равно привлекают внимание, показывая открытость перед пользователем.
3. Оптимизация по ключевым словам. Это полезно не только для продвижения в поисковиках, но и для визуального восприятия. Зайдя в описание приложения «Блокнот», пользователь наверняка будет искать глазами слова «закладки», «навигация» и подобные. Если они не вынесены в список, стоит их хотя бы разместить в тексте.

Правило 4. Декларируйте обновления и исправления

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

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

Правило 5. Не скромничайте

Описание наград и достижений, даже сомнительных — это возможность привлечь внимание. Пусть это будет хоть «Приз зрительских симпатий моих друзей» или «Худшее приложение года по версии NY Times (если бы у них была такая номинация)». Нескромность и ирония вызовут в данном случае лишь умиление. Если у вас есть другие популярные приложения или количество скачиваний текущего впечатляет — надо заявить об этом в описании.

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

Воспользуйтесь этими правилами — и получите название, которое поможет вашему приложению резво стартовать.

Что важно учесть при использовании этого инструмента, объясняет Сэм Уэлч (Sam Welch), директор по стратегии в 3Q Digital. Перевод статьи «How to maximize value from push notifications»

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

Приступим.

Push-уведомления: лучшие базовые практики

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

Предложите нечто ценное. Зачем клиенту ваши push-уведомления? Он узнает о закрытой распродаже? Увидит забавный контент? Главное, чтобы пользователь видел смысл получать уведомления, а в них самих было что-то, доступное только через приложение и никак иначе.

Визуализируйте. Уведомление с картинками и видео доносит историю лучше, чем простой текст, так как больше затрагивает эмоции. Исследование от Urban Airship показало, что включение графики в пуш-уведомления может повышать открываемость на 56 %. Если вы предлагаете товар по распродаже, добавьте его фото. Если срок акции ограничен — разместите часы. Не обязательно мудрствовать.

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

Получаем согласие на уведомления: лучшие способы

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

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

Выберите правильный момент, чтоб запросить разрешение. Не предлагайте включить уведомления сразу — пользователи еще не знают, что вы можете им предложить. Дайте им сначала исследовать приложение. Когда у них появится потребность в том, что может дать уведомление — запрашивайте согласие на показ. Если у вас приложение интернет-магазина — дождитесь, когда пользователь отправит первый заказ. Пусть приложение подскажет: «Хотите включать push-уведомления, чтобы мы могли сообщить вам, когда заказ будет готов?»

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

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

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

Увяжите типы уведомлений с поведением клиента

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

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

С другой стороны, если юзер часто открывает приложение, стоит побудить его сделать заказ — особенно накануне выходных или праздников. Можете почаще напоминать о товаре. Например, если пользователь сервиса Amazon добавил гриль в корзину в июне, есть хороший шанс, что он захочет купить его к 4 июля. (День независимости в США, выходной — прим. пер.)

Увяжите типы уведомлений с предпочтениями клиентов

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

Маркер «В сфере интересов». Если пользователь обращается к товару в приложении и на сайте, можно говорить о позитивном отношении к этому продукту.

Маркер «Вне интересов». Если пользователь игнорирует рекламные сообщения и рассылки о конкретных продуктах, это свидетельствует об отсутствии внимания к товарам данного типа.

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

Тщательно продумайте расписание показа push-уведомлений

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

Из опыта, приобретенного за время пуш-кампаний, мы можем дать четыре рекомендации:

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

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

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

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

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

Решите, уведомления какого типа использовать

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

Приветственный пуш

Pizza Hub в приветственном пуше дарит скидку — и этим сразу показывает клиенту, зачем получать уведомления.

Пуши на основе предпочтений

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

Пуш-напоминание о незавершенном заказе

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

Пуши от службы доставки

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

Тематические пуши

Радиостанция iHeartRadio увязывает свои пуши с Месяцем женской истории (в марте в Британии, Австралии и США принято подчеркивать вклад женщин в мировую историю и развитие современного общества — прим. пер.). Такие пуши смотрятся органично и своевременно. Чем более ваша рекламная кампания или CTA (от англ. call to action — «призыв к действию») связана с актуальными событиями в жизни пользователя, тем лучше сработает тематический пуш.

Продвигающий пуш

Бренд одежды Charlotte Russe использует верхний регистр, чтобы обратить внимание на свои продвигающие пуши. Их уведомления объясняют повод распродажи («счастливый час») и сообщают пользователю все, что нужно знать для участия в акции.

Выводы

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

А как вы относитесь к пушам? Отключаете? Или может, у вас есть скриншоты с интересными и прикольными уведомлениями?

Разработчик мобильного приложения GeekBrains Даниил Скрипник провел в офисе Mail.Ru Group открытый воркшоп по работе с фреймворком React Native. Участники за пару часов самостоятельно написали мессенджер и увидели, как технология позволяет сэкономить время и усилия программиста.

Мы попросили Даниила рассказать, как он начал работать на React Native и почему он хочет научить этой технологии коллег.

Сначала я ушел из логистики и за полгода переучился на frontend-разработчика

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

Записался на онлайн-курсы в Школу-партнер Micrоsoft, занимался почти сутками и за 6 месяцев освоил тот минимум, с которым можно было найти работу или стажировку front-end разработчика: HTML&CSS, HTML5&CSS3, JavaScript, Bootstrap, JQuery, Angular.JS. Прошел стажировку в нескольких компаниях, получил от каждой из них предложения по работе. Но они работали с устаревшим стеком технологий и мне это было неинтересно.

Попробовал React Native и начал писать приложения

В результате я устроился на работу в Alpha Design. Компания занимается разработкой и дизайном для Apple, Rakuten, Amazon. Сначала я занимался только frontend-разработкой. Но в какой-то момент у нас появился заказчик – владелец глянцевого журнала, который хотел создать приложение для поиска и покупки одежды. По сути, это была соцсеть, похожая на Instagram, где ты листаешь фотографии с одеждой и можешь купить то, что тебе понравилось. В Alpha Design не было мобильных разработчиков и мы решили делать кроссплатформенное приложение на React Native.

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

Мне понравилось, как быстро с помощью React Native можно сделать что-то осмысленное, продукт, который сразу начинает работать. Front-end в сравнении c мобильной разработкой показался мне более долгим и ограниченным. Меня впечатлила скорость, с которой я мог писать приложения на несколько платформ с нуля.  

Написал три приложения за год

Я начал искать работу в этом направлении. Написал в чат проекта Hexlet, что умею, и спросил, где можно поработать с такими навыками. Мне ответил владелец компании Evrone, которая занимается Ruby-разработкой, и предложил присоединиться к их международной команде, которая работает удаленно. Сначала я работал на них из Сербии, а позже переехал в Москву.

За год я поработал над тремя приложениями, которые с нуля создавались на React Native: «Дневник еды», Pinpil (приложение по поиску аптек) и Криптокошелёк для стартапа Humaniq.

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

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

Криптокошелек для стартапа Humaniq частично разрабатывался на Android, частично на React Native. Эта компания собрала на ICO 15 млн долларов и придумала приложение для людей, которые не умеют писать и читать (было нацелено на использование в африканских странах). Все управляется с помощь face id, иконок, голосовых сообщений. Было интересно работать над его прототипом.

Написал приложение для Mail.Ru Group и попробовал преподавать

Пока я работал в Evrone, я получил предложение от рекрутеров Mail.Ru Group. Они искали мобильного разработчика на React Native, чтобы написать кроссплатформенное приложение для сайта GeekBrains. Я успешно прошел собеседование и с удовольствием начал работать над этим интересным проектом. Версия под iOS и Android уже доступна для скачивания, но мы продолжаем разработку.

Став мобильным разработчиком в Mail.Ru Group, я также смог попробовать себя в качестве преподавателя. Мои коллеги, разработчики Java, поехали преподавать программирование школьникам из лагеря для одаренных детей «Сириус». Я решил к ним присоединиться и взял группы по обучению мобильной разработке. Это был интересный опыт. Я понял, что задача преподавателя – не отвечать на все вопросы подряд, тем более, что они часто одни и те же. Главное – научить студентов самостоятельно находить ответы и решения для своих задач.

Когда я вернулся в Москву, я захотел что-то подобное провести для своих коллег. Сначала провел воркшоп по React Native для сотрудников Mail.Ru Group,  а позже, когда получил положительные отзывы от коллег, мы провели открытый воркшоп для слушателей из других компаний.

Придумал свой формат для воркшопа React Native

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

На первую встречу пришли мои коллеги — мобильные разработчики и frontend-разработчики из Mail.Ru Group. На втором воркшопе, который также прошел у нас в офисе 20 апреля, были представители Яндекса, Альфа-Банка, СберТеха, МФТИ, студенты и преподаватели GeekBrains, ВШЭ, Тинькофф, HeadHunter. Также было несколько владельцев веб-студий.

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

Я понимаю, что у технологии React Native есть свои критики. Они есть и среди тех, с кем я работаю бок о бок.  Но я вижу, как много времени и усилий я сейчас экономлю на мобильной разработке, как много ресурсов Facebook и другие IT-гиганты сейчас вкладывают в ее развитие. Я искренне считаю React Native очень полезным и для front-end разработчиков, и для мобильных программистов.

Почему React Native – это круто?

React Native – это фреймворк для создания кроссплатформенных приложений на языке JavaScript. Он позволяет писать приложения для IOS, Android, Windows Phone и даже VR (на React VR можно создавать приложения для шлемов и очков виртуальной реальности»).

React Native – это отличная возможность быть быстрым и пользоваться любимыми инструментами «прямо из коробки» (их не нужно настраивать, они работают здесь и сейчас): CSS, ES6, ES7, NPM, Yarn и т.д.

Создатель React Native – Facebook, лидер во front-end, компания, которая вкладывает огромные ресурсы в развитие своих технологий. Facebook активно развивает React и React Native, создает вокруг них целую инфраструктуру и мощное IT-сообщество.

Еще одно преимущество технологии – быстрорастущее комьюнити из компаний, которые используют технологию, инвестируют в нее и поддерживают ее развитие: GeekBrains, Yandex, Airbnb, Wix, Tesla, Soundcloud, Walmart.

На этом фреймворке написаны UberEats, FacebookGroups и частично Instagram и Facebook.

Срок жизни мобильного приложения зависит от любви пользователей. Чем сильнее любовь, тем дольше приложение востребовано, и тем больше создатели на нем заработают. Для анализа поведения пользователей собирайте статистику, переводите ее в метрики и анализируйте их. Это позволит понять слабые места продукта и своевременно провести корректировку функций или интерфейса. Выберите подходящий сервис аналитики для мобильных приложений. Самые популярные: Google Analytics, AppMetrica от Яндекс, AppAnnie, Flurry и Mixpanel.

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

Популярно ли приложение?

Чтобы это узнать, смотрите на общее количество пользователей и на количество новых пользователей. Это два показателя: Total Users и New Users. Показатели рассчитываются на заданную дату, поэтому анализируйте динамику их прироста. Для привлечения New Users используйте рекламу и маркетинговые активности. Следите, чтобы приток новых пользователей покрывал отток (Churn Rate), иначе приложение останется без аудитории.

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

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

Когда бить тревогу?

1. Приток новых пользователей ниже оттока — New Users < Churn Rate.
2. Показатели DAU и MAU равнозначны, значит, подавляющее число пользователей — «однодневки».
3. Users Online превышает максимальную нагрузку на сервер.

Как узнать, довольны ли пользователи?

Для этого используйте две группы метрик: Retention и Activity. Показатели Retention считают количество вернувшихся пользователей и динамику их изменения. Как правило, смотрят долю вернувшихся на следующий день (1-day retention), через неделю (7-day retention) и через месяц (30-day retention). В группу Activity входят показатели Users Online, Sessions, Average Sessions Length и Life Time.

Если пользователи довольны опытом взаимодействия с приложением, они вернутся снова. Поэтому отслеживайте метрики 1-day и 30-day retention. Если 1-day retention низкий, вероятнее всего, в приложении есть проблемы: огрехи в юзабилити, неудобство интерфейса или непродуманные пользовательские сценарии. Метрика 30-day retention показывает долю пользователей, которые обычно становятся ядром лояльной аудитории.

Гипотетически метрики day retention могут быть равны 100%. Это может случится, если все пользователи, которые скачали приложение, остались верны ему навечно. Но на практике это невозможно, поэтому добивайтесь, чтобы показатели росли в динамике. Для этого отслеживайте Retention Dynamics. Найдите все скачки на графике и попробуйте понять, с чем они связаны: сезонность, реклама, специфические закономерности и др.

Отдельно следите за Sticky Factor — показателем регулярности посещений. Он рассчитывается как соотношение DAU к MAU. Чем выше значение, тем чаще пользователи в среднем заходят в приложение. Если Sticky Factor ниже 3%, пользователи заходят в приложение реже одного раза в месяц. Стремитесь к значению 50%.

Чтобы узнать, как часто пользователи заходят в приложение, разделите общее количество посещений (Sessions) на показатель DAU. Идеальные показатели зависят от типа приложения. Например, для длительных мобильных игр отличным значением будет 2 сессии в день, для коротких игр — 4-5 сессий в день.

Считайте среднюю продолжительность одной сессии — Average Sessions Length. Значения также разнятся по видам приложений. Желательно, чтобы для игр или чтения показатель был большим, а для сервисов вызова такси или заказа еды — низким. При рекламной монетизации стремитесь к максимальному показателю — 30 минут.

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

Когда бить тревогу?

1. Низкие показатели day retention.
2. Retention Dynamics имеет отрицательный рост.
3. Sticky Factor меньше 3%.
4. Снижение Life Time.

Сколько денег приносит?

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

Еще рассчитывают Average Check — средний доход на одну транзакцию. Для расчета разделите значение Gross на количество транзакций, и вы получите средний чек. Если каждый платящий пользователь платил всего один раз, то метрики Average Check и ARPU будут совпадать.

Доход на каждого пользователя рассчитывается показателями ARPU и ARPPU. Показатель ARPU (Average Revenue Per User) — это средний доход на одного пользователя. Показатель ARPPU (Average Revenue Per Paying User) — это средний доход на одного платящего пользователя. Обе метрики считают за выбранный период. Дополнительно рекомендуем посчитать показатели отдельно для каждого среза целевой аудитории: для новых пользователей, для постоянных, для пользователей с разным Life Time.

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

Когда бить тревогу?

1. Gross и Revenue существенно меньше запланированных в бизнес-плане.
2. ARPU и ARPPU существенно ниже средних по отрасли.

Выгодно ли приложение?

Если не брать в расчет затраты бизнеса, быстро оценить рентабельность мобильного приложения позволяют метрики CPI и LTV. Первый показатель — это Cost per Install, т.е. средняя стоимость установки приложения. Для его расчета разделите общие расходы на рекламу и маркетинг на количество установок за весь период работы приложения. Показатель LTV (Lifetime Value) показывает средний доход, который приносит один пользователь за все время использования продукта. Для его расчета перемножьте показатели ARPU и Life Time. Метрика показывает общую доходность приложения.

Следите, чтобы затраты на установку приложения всегда были ниже дохода, который приносит один пользователь. Чем дольше пользователь работает с приложением, тем выше доход он принесет разработчикам. Если приложение монетизируется только за счет показа рекламы, то один пользователь должен приносить 10$ за год. Это примерно 10-12 минут посещения приложения ежедневно.

Когда бить тревогу?

• Показатель CPI ниже ARPU;
• Показатель CPI ниже LTV.

Сможет ли принести больше денег?

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

Обратите внимание на динамику изменений Paying-метрик. Если показатель Paying Share низкий или падает, значит, платный контент не интересен. Стимулируйте пользователей совершать покупки: вводите новые платные опции, запускайте скидки, продавайте подсказки. Найдите на графике сильные скачки конверсий и разберитесь, что повлияло на резкий рост. Когда найдете причину или закономерность, внедрите это в стратегию монетизации.

Каждая оплата пользователя фиксируется сервисом статистики: кто оплатил, когда и сколько. На основании данных для анализа доступны метрики Transactions и Transactions by User. Первая метрика — это общее количество платежей за выбранный период. Вторая — среднее количество платежей на одного пользователя.

Чтобы высчитать Transactions by User разделите общий объем транзакций на значение Paying Users. Показатели транзакции демонстрируют, насколько пользователи вообще готовы платить. Если значение Transactions by User больше 1, пользователи совершают более одной покупки. Если меньше, то покупки в приложении происходят редко.

Когда бить тревогу?

1. Paying-метрики сильно снижаются.
2. Transactions падает.
3. Transactions by User меньше 1.

Запомните

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

Подборка

Тем, кто интересуется мобильными приложениями, рекомендуем другие статьи в блоге по теме:

Про выбор и тестирование идеи

О дизайне

О дизайне-2

Про монетизацию

О выборе языка программирования

О выборе языка программирования-2

Про ошибки в iOS разработке

Подбор площадок для тренировки навыков программирования на Swift

Интервью с профильным преподавателем и деканом факультета

Вебинары

Objective-C vs Swift. С чего начать

Введение в iOS-разработку

Введение в iOS, MVC и Objective-C

Будущее уже здесь! React Native: один код для iOS и Android

Бесплатные курсы

Android. Быстрый старт

Интенсив «Программирование на Swift с нуля»

Приглашаем на воркшоп по React Native в офисе Mail.Ru Group 20 апреля!

Автор воркшопа — разработчик мобильного приложения GeekBrains Даниил Скрипник.

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

Для кого воркшоп?

Этот воркшоп будет полезен всем, кто хочет познакомиться с мобильной разработкой и для тех, кто знаком с React и JS.

Что такое React Native и почему это круто?

Это фреймворк для создания кроссплатформенных приложений на языке JavaScript. Он позволяет писать приложения для IOS, Android, Windows Phone и даже VR (на React VR можно создавать приложения для очков виртуальной реальности).

React Native — это отличная возможность быть ленивым и пользоваться любимыми инструментами «прямо из коробки» (их не нужно настраивать, они работают здесь и сейчас): CSS, ES6, ES7, NPM, Yarn и т.д.

Создатель React Native — Facebook, лидер во front-end, компания, которая вкладывает огромные ресурсы в развитие своих технологий. Facebook активно развивает React и React Native, создает вокруг них целую инфраструктуру и мощное IT-сообщество.

Еще одно преимущество технологии — быстрорастущее комьюнити из компаний, которые используют технологию, инвестируют в нее и поддерживают ее развитие: GeekBrains, Yandex, Airbnb, Wix, Tesla, Soundcloud, Walmart.

На этом фреймворке написаны UberEats, FacebookGroups и частично Instagram и Facebook.

Кто будет вести воркшоп?

Даниил Скрипник — разработчик мобильного приложения GeekBrains.

Когда-то Даниил работал операционным менеджером по морским и авиаперевозкам в логистической компании, но решил сменить профессию и стать программистом. Он закончил Школу Microsoft, где освоил стек фронтенд-разработчика.

С технологией React Native Даниил познакомился, когда работал в компании Alpha Design в Сербии (партнер Apple, Amazon, Rakuten) и написал прототип кроссплатформенного приложения для покупки одежды.

После этого он работал в компании Evronе и за год написал на React Native три приложения: Дневник еды, приложение по поиску лекарств Pinpill и Криптокошелёк (собрал на ICO 15 млн долларов).

Позже получил предложение о работе от Mail.Ru Group и начал разработку приложения GeekBrains (версия под IOS уже доступна для скачивания).

В каком формате будет проходить воркшоп?

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

Практическая часть — главная, как говорит сам Даниил. За пару часов вы напишете мессенджер на React Native и начнете переписываться с другими участниками воркшопа.

Даниил уже проводил воркшоп по React Native для сотрудников Mail.Ru Group. Участникам очень понравилось, как формат мероприятия раскрывает особенности этой технологии, поэтому мы с Даниилом решили повторить его для более широкой аудитории.

Куда идти и что делать?

Для работы на воркшопе вам понадобится ноутбук.

Регистрируйтесь на мероприятие здесь.