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

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

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

  1. Как лучше разрабатывать — нативно или кроссплатформу?
  2. Что выпустить первым — Android или iOS?
  3. Можно ли как-то протестировать приложение перед релизом на живых пользователях?
  4. Стоит ли открыть игру сразу на весь мир или только в одной стране?
  5. Как привлечь в свое приложение пользователей, если бюджет на это ограничен или его вообще нет?
  6. Как вообще узнать, хороши или плохи показатели моего приложения? Как узнать, если в нем есть проблемы и проблемные места?
  7. Как часто стоит обновлять приложение?
  8. Можно ли посмотреть, откуда приходят пользователи?
  9. Стоит ли встроить в приложение рекламу или это отпугнет пользователей?
  10. Что вообще встроить в приложение, чтобы не упустить чего-то важного?

Три года назад у меня тоже не было ответов на эти вопросы, зато они есть сейчас. Ещё три-четыре года назад мобильная индустрия вообще была в зачаточном состоянии, и половины важных и нужных инструментов просто не существовало. Зато сейчас у нас с вами есть почти всё, о чем можно мечтать. Главное — знать, куда смотреть и где искать. Меня удивляет, что в сети до сих пор нет ни одной грамотной и полезной информации для новичков. Хотя, возможно, я их просто не встречал.

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

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

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

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

Кроссплатформенные движки сейчас вышли на очень хороший уровень, обзавелась массой облегчающих инструментов. Поэтому, что бы вы ни делали, что бы ни проектировали, изучите сначала вопрос кроссплатформенной разработки. Должны быть очень сильные аргументы, чтобы от неё отказаться. Я много общаюсь с разработчиками, которые делают приложения на заказ, и все они хором кричат «Не делайте кроссплатформу!». Но тут есть нюанс: нативная разработка (отдельно iOS и Android) в два раза увеличивает сроки и ресурсы.

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

«Сниженная производительность»

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

«Более отзывчивый интерфейс, высокая скорость работы»

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

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

Да, в России огромный парк слабых устройств на Android (порядка 40% от всех смартфонов), и это, пожалуй, самый большой минус кроссплатформы. И тут вам нужно определиться: вы хотите охватить всех? Даже самых малообеспеченных со слабыми устройствами? Тогда это аргумент не в пользу кроссплатформенного решения. А вообще, идите на сайт движка, там всегда огромное количество примеров, ищите что-нибудь близкое, скачивайте, запускайте на слабом устройстве и смотрите сами. Тормозит? Сильно?

«Кроссплатформа будет очень дорога в обслуживании»

Это второй наиболее распространенный аргумент, и он меня всегда ставит в тупик. Каким образом сокращение ресурсов в два раза удорожает поддержку проекта? Задайте этот вопрос. Есть, конечно, нюанс: сложнее найти специалиста, иногда бывают сложности с плагинами и библиотеками, но неужели это плюс 70−100% ко времени? Задавайте конкретные вопросы: что конкретно удорожит обслуживание?

«Будут большие проблемы с плагинами, библиотеками и SDK»

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

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

Иногда приложение требует нативных интерфейсов, а они на iOS и Android разные. Если у вас именно такое приложение или вы влюблены в material design (как я), то да, кроссплатформа вам не подойдет.

Но я не встречал нигде никаких данных, которые говорили бы, что пользователи уходят из приложения только потому, что его интерфейс не нативен. Он должен быть удобен, красив, но обычные пользователи, как правило, не оперируют соображениями нативности и вряд ли сбегут в ужасе, выкрикивая: «Это не нативно!». В конце концов, есть fixel и murl, которые используют нативный код без прослойки, но это почти экзотика.

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

Что выпустить первым — iOS или Android

Ещё год назад я бы сказал, что iOS. Просто в силу более понятной структуры и меньшего парка устройств, а это экономия на тестировании и времени. Но сейчас я точно отвечу, что Android. Google за последнее время добавила просто массу незаменимых инструментов в консоль разработчика, которых нет ни в iTunes Connect (консоль разработчика от Apple), ни где-либо ещё.

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

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

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

Зато в Google Developer Console сейчас есть почти всё для того, чтобы тестировать, проводить эксперименты и повышать эффективность мобильного приложения.

Инструмент «Эксперименты»

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

Если вы всё-таки стартовали с iOS, то вам поможет Splitmetriсs. Один эксперимент вам дадут сделать бесплатно, потом — $250 в месяц. По-моему, нещадно.

Альфа-тестирование

Добавляете почтовый ящик в тестеров, консоль генерит тестовую ссылку, по которой можно скачать тестовую версию игры. Нетривиально, будьте осторожны. Работает, только если на устройстве вы используете браузер Chrome, а не старый Internet.

В iTunes Connect есть аналог — Testflight. Работает почти так же, только для завершения процесса регистрации использует исключительно Safari (будьте внимательны: если вы прямо из почтового приложения перейдете по ссылке, то увидите ошибку; вы должны открыть её на устройстве в Safari). Чтобы скачать тестовую версию на устройство, придется скачать одноименное приложение из App Store. В своё время я убил пару дней, пытаясь разобраться, как работает эта монструозная связка.

Бета-тестирование

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

Информация по конверсии из просмотра в скачивание

Это есть и у Apple. Позволит понять, всё ли хорошо со скриншотами, описанием, иконкой и так далее. Забегая вперёд, скажу, что средняя конверсия — 10%, для игр часто меньше. Известный мне максимум — 65%.

Если конверсия низкая, меняйте по очереди весь маркетинг, делайте А/В-тесты, упирайтесь до последнего. Это ключевой показатель для успешности вашего проекта. Ничего важнее просто нет (кроме показателя удержания пользователей или retention).

Быстрое одобрение

Занимает не более шести часов. В Apple недавно наконец-то сократили время рассмотрения приложения до двух дней. Аллилуйя! Есть непроверенное ощущение: если вы выйдете в пятницу или четверг, то есть шанс, что это время сократится до нескольких часов. У меня пару раз игра выходила через два часа после выливки. Раньше даже expedited review не давало такого результата.

Статистика по крашам и неожиданным закрытиям приложения (ANR)

Не работает на кроссплатформе, к сожалению, но в остальном бывает полезна. Только смотрите их не через «Сбои и ANR», а через следующий путь: «Статистика» > «Сбои за день» > «Подробности сбоев». Не знаю почему, но именно этот путь открывает нужные подробности, которые можно использовать. Кстати, в Google Analytics с полгода назад тоже добавили сбои. Они там подробные и работают даже на iOS.

Возможность отвечать на комментарии к приложению

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

Весь маркетинг проходит процесс одобрения только при выливке нового билда

Если вы меняете только маркетинг (описание, скрины и прочее), то новые появятся в Google Play уже через час-два и автоматически. Это иногда критично на первых стадиях, когда именно маркетинг будет основным объектом ваших экспериментов и изменений, а собирать новый билд каждые два дня у вас нет возможности.

У Apple вы можете без нового билда обновить только описание. Всё остальное — только с новой версией приложения. Единственный плюс — вы можете свободно менять маркетинг, пока приложение ждет ревью, но и тут есть подстава: после отправки новой версию на ревью вы уже не сможете добавить локализацию.

Тестирование уведомлений

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

Отчет о тестировании

Это тестирование на живых устройствах, добавлено недавно). Обалденная штука. Запускается автоматически, как только вы выпустите альфа- или бета-версию. Запускаются скрипты, которые проводят основные операции типа запуска, пролистывания, набора текста. Бесплатно. Даже скриншоты вам покажут с протестированных устройств. Если захотите более полных тестов — добро пожаловать в Firebase Test Lab там же, но это уже платно.

В iTunes Connect либо нет этих инструментов, либо аналоги неудобны. Ну, или у меня не хватило сил, терпения и времени, как с Testflight, чтобы разобраться, как оно работает. Например, я вижу, что у меня 100 сбоев — конечно, хочу тут же их пофиксить, кликаю на цифру, а мне показывают график. Зачем он мне? Мне нужен лог сбоя, чтобы его оперативно исправить, но найти его так и не удалось. Возможно, более сообразительные коллеги помогут? Буду очень благодарен.

Поэтому если вы новичок или просто здравомыслящий человек, полагающий, что любой проект на старте — это тестовый образец, требующий анализа, улучшений и повышения эффективности всеми возможными способами, то только Google Play Developer Console (GPDC) даст вам почти все инструменты, чтобы довести приложение до ума.

Что нужно встроить в приложение

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

Статистика

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

Обе платформы с недавнего времени внимательно следят за показателями вовлеченности пользователей, и этот показатель напрямую влияет на то, как ваше приложение будет отображаться в поисковой выдаче. Если показатель вовлеченности (retention) у вас ниже, чем у конкурентов, вы будете проигрывать гонку в поисковой выдаче Google Play. У меня такое ощущение, что и App Store уже экспериментирует с этим. Поэтому статистика — ваше всё.

На рынке есть много решений: Flurry, Google Analytics, Amplitude. В каждом из них есть свои плюсы и минусы: Flurry данные собирает два дня, в Google Analytics не очень удобно работать с сегментами и строить воронки, нет User Path. Amplitude, хоть и самое удобное и мощное решение из этих трех, имеет очень ограниченный бесплатный пакет событий.

Я использую одновременно Flurry и Google Analytics: они показывают картинку по-разному, и иногда её нужно дополнить второй статистикой, чтобы увидеть ее целиком. Ваша задача на первом этапе — видеть каждый шаг вашего пользователя. Особенно важна первая сессия: именно она либо приведет ко второй, либо не приведет. Заведите максимально подробные события, отслеживайте практически каждый клик, чтобы увидеть, где отваливаются ваши пользователи, на каком шаге, и что нужно исправить.

Атрибуция, она же трекинг

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

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

Какие решения для трекинга у нас есть на рынке? Их много, я знаком с несколькими:

AppsFlyer — идеальное решение для новичка. Всё просто и понятно. Платите за установки приложения (5 центов), но, по моему личному опыту, счет вам не выставят, пока вы в месяц не натрекаете на $100. Миллион интеграций с разными рекламными источниками, даже есть Facebook, а он давно уже ни с кем не интегрируется.

Tune (раньше Mobile App Tracking и HasOffers) — сложное решение. Тормозной интерфейс (возможно, исправились, я уже год как не пробовал). Если вы не сталкивались, то вам будет очень сложно с этим работать. Зато очень подробная и детальная аналитика. На первых порах вам это не понадобится. К тому же дорого, берут деньги и за клики, и события.

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

Есть ещё Adjust (его очень любят западные коллеги), AdX (не знаком), а Mail.ru вот уже с полгода тянет с выпуском собственного трекера, ждем-с.

Обратная связь прямо из приложения

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

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

Поэтому сделайте большую кнопку «Обратная связь», запускайте почтовое приложение при нажатии или встройте SDK Zendesk — оно как раз для таких случаев. Не забудьте при этом в теме письма автоматически указывать название приложения, а в подписи тоже автоматом писать данные пользователя: операционную систему, устройство, страну, версию приложения, идентификатор пользователя (если таковой есть). Вам это точно потребуется для локализации проблемы. Zendesk это сделает для вас автоматически.

А/В-тесты

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

Если вы новичок, то просто послушайте моего совета: не ходите в Store без А/В-тестов гулять. Реализуется элементарно, польза неоценима. Я это делаю с помощью конфигурационных файлов.

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

Итак, чтобы всё измерить, мы создаем два-три разных конфигурационных файла (конфига).

  1. Вызывает окно регистрации на старте
  2. Вызывает окно регистрации после того, как пользователь вовлечен (прошел второй уровень или прочел две-три статьи, например).
  3. Вообще не вызывает окно регистрации.

Ставите случайное распределение и раздаете на старте пользователям конфиги в случайном порядке, при этом шлете в статистику соответствующее событие (получен конфиг 1).

Я в дополнение к каждому событию в игре (пользовательские действия) прицепляю метку с номером конфига, чтобы уже точно можно было делать любые срезы. В Google Analytics такие метки называются Labels, а во Flurry — Parameters. Потом мы сможете создать сегменты по признаку А/В-группы (по событию получения определенной группы во Flurry или по признаку Лейбла в Google Analytics) и смотреть любые события в игре в разрезе этих групп.

Иными словами, сможете ответить на вопросы типа: «Сколько процентов людей из первой, второй и третьей группы дошли до 10 уровня?», «Сколько процентов людей из этих групп запустили приложение на второй день?», «Сколько процентов совершили покупку в моем приложении?».

Возможность поставить оценку приложению

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

Будьте осторожны: нельзя мотивировать пользователей поставить именно пять звезд, такое приложение не пройдет модерацию. Многие активируют такую возможность удаленно уже после релиза, но я бы так не рисковал: в Google сомнительные обзоры могут просто стереть, а в Apple могут и позвонить вам с разбирательством (у меня такое было). Лучше устройте А/В-тест и оставьте наиболее эффективный сценарий.

Статистика по падениям приложения

Головная боль. Почему-то до сих пор ни одна из консолей не предоставляет полного доступа к крашам приложения. Краш-репорты в iTunes Connect вообще куда-то делись, а в Google Play зачастую тоже недостаточно информации, какой из процессов вызвал падение, особенно если у вас кроссплатформа.

Что у нас есть? Знаменитая Crashlitics (теперь Fabric) недавно стала бесплатной, пробуйте обязательно. Краши есть во Flurry в разделе Technical (странно отсортированы и в большинстве случаев бесполезны), есть они и в Google Analytics (почему-то в разделе «Поведение») — появились недавно и на удивление информативны. Ну и в самой Google Developer console, конечно. Как их найти, я написал выше.

На краши в iTunes Connect не надейтесь: их мало (пользователь должен дать согласие на отсылку, а ему это не нужно), там ничего не понять, и в результате последнего изменения я вообще не могу найти, куда их запрятали.

Уведомления

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

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

Форс-апдейт

Это такая штука, которая позволит вам не бояться ошибиться. Очень простая система, которая каждый раз при старте приложения стучится на ваш сервер и проверяет номер актуальной версии. Если версия устарела, показывается окно «Обновитесь». Будьте внимательны, на Android такие окна иногда можно отменить физической кнопкой «Назад», не позволяйте этого.

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

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

Шифрование

Поставил последним: это не обязательно, но тоже может уберечь от разных просчетов. Особенно это касается приложений с платежами. По статистике 90% платежей в России — взломы.

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

***

Хотел ещё пройтись по темам, как стартовать, на что обратить внимание и как работать с трафиком, но сделаю отдельно, если вам будет интересно. А пока будем считать, что у кого-то теперь есть памятка, как подготовиться к релизу. Я бы в свое время убил за нечто подобное.

0
127 комментариев
Написать комментарий...
Victoria Shintekova

Хорошая статья! Я бы ещё сюда добавила branch.io . Помимо простой реализации deeplink-ов, позволяет ставить метки на ссылки и отслеживать при установке, откуда пришёл пользователь. В зависимости от источника можно менять поведение приложения.

Ответить
Развернуть ветку
Константин Нелюбин

Виктория, спасибо. А чем отличается от любого другого трекера? Как это менять поведение приложения? Можете чуток рассказать? Сегментация на основе источника трафика?

Ответить
Развернуть ветку
2 комментария
Yury Nechaev

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

Если кинут в руки клавиатуру и скажут: "Сыграй на гитаре", ты кинь ее обратно со словами "Сначала настрой".

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

Ответить
Развернуть ветку
Ildar Karimov

Ненативные ("кроссплатформа") приложения имеет смысл делать в двух случаях:

1) Игры - тут всё очевидно и, понятное дело, никакого webview тут не используется - только натив (в смысле компилируемые языки, а не js/html/css), только хардкор!

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

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

Ответить
Развернуть ветку
Ildar Karimov

Благодаря спорам в комментариях понял, наконец, как нужно правильно сформулировать возможность применения ненативных инструментов для "приложений с нативным UI": если приложение - это бонус к вашему основному бизнесу, то можно начинать с кроссплатформы (но аккуратно). Сюда относится B2B и прочий энтерпрайз (какое-нибудь приложение лучше отсутствующего, конечно), приложение сети кинотеатров (деньги зарабатывают на билетах всё-таки, а не чисто самим приложением), приложение интернет-магазина (но тут уже есть нюансы, а конкурентов много). Да собственно мобильный фейсбук вполне можно было считать лишь приложением к сайту пять лет назад, им пользовались единицы процентов в лучшем случае. Если же ваш бизнес - само приложение на конкурентное рынке (100501-й менеджер задач, мессенджер, тиндер или даже фонарик), то делайте только натив, на кроссплатформу только зря деньги потратите.

Ответить
Развернуть ветку
3 комментария
Artem Osipov

Я вот тоже пришел сюда, чтобы поговорить о нативном UI.
Например воспроизвезти гладко и без глюков новый material в android с помощью webview будет стоить очень дорого и все равно не выйдет так же гладко. Можно посмотреть http://fezvrasta.github.io/bootstrap-material-design/ как пример. Совсем не огонь же :)
В результате придется пилить UI под две платформы все равно и везде извращаться что в итоге выйдет дороже.

Ответить
Развернуть ветку
13 комментариев
Константин Нелюбин

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

Ответить
Развернуть ветку
4 комментария
Aleksander Alhoff

Прикольно когда приложение вначале спрашивает сама все ли ок или есть проблемы.

И только тех кто ответил "ок" отправляет оставлять отзыв в store, а тех кто ответил "не ок" в форму обратной связи.

Часть приложений которые такой способ не юзают сами провоцируют появление негативных отзывов

Ответить
Развернуть ветку
Константин Нелюбин

Тут есть нюанс. Я пробовал такой подход - делал в окне 2 кнопки "Нравится? Оцените!" и вторая "Сообщить о проблеме". Делал их разными цветами и пр. Но результат был не совсем ожидаемым. Из-за наличия сразу 2 кнопок конверсия в оценки снизилась почти в 2 раза.
Короткие четкий призыв оценить работает намного эффективнее. Главное протестировать хорошо.

Ответить
Развернуть ветку
Leonid Bogolubov

Такое уже Apple запретила.

Ответить
Развернуть ветку
4 комментария

Комментарий удален модератором

Развернуть ветку
Artem Voronov

Вопросы кроссплатформа вызывает только у тех, кто за свои деньги ни разу не делал проект под несколько платформ. По статье же, можно уточнить, основываясь на опыте разработки на Xamarin:
- Проблем с плагинами и SDK нет. Всегда можно написать свой wrapper и работать с ними. И уж точно нет никаких проблем с Material Design, работа с ним никак не отличается.
- И бэкэнд и мобильные клиенты могут писать одни и те же люди. Нет затрат времени на выяснения, на чей же строне косяк. в своем проекте Android, iOS и бэкэнд в одно лицо тяну без особых проблем. Платформенного кода всего около 20%.
- Про производительности тоже тема давно раскрыта на практике http://magenic.com/Blog/Post/4/Mobile-Development-Platform-Performance http://stackoverflow.com/questions/17134522/does-anyone-have-benchmarks-code-results-comparing-performance-of-android-ap

Ответить
Развернуть ветку
Ildar Karimov

А покажите ваше приложение, пожалуйста.

Ответить
Развернуть ветку
3 комментария
Константин Нелюбин

100500 за! Это именно тот ответ, которого я ждал. На собственном недавнем опыте с цифрами и примерами. Спасибо!

Ответить
Развернуть ветку
Hoffman

Что конкретно подразумевается под "кроссплатформой"? Если основанные на webview (PhoneGap и т.д.), то о какой "такой же" производительности речь? Это тормозящий кусок говна, который нормально работает только на айфонах (да, в Андройдах использовался webview Хрома, а не родной). Про Ксамарин ничего не знаю. Если речь про React Native, то все очень круто, но пока тоже очень тупит и те приложения, которыми люди пользуются (а не те, которые "просто так"), либо переписывают отдельные компоненты нативно, либо полностью переделывают приложения.

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
4 комментария
Константин Нелюбин

Да я вроде даже перечислил всё, что в таком ключе рассматриваю. Там 6 кроссплатформенных поименованы. Юнити в том числе.

Ответить
Развернуть ветку
3 комментария
Marina Bril

Спасибо, хорошая статья, буду шерить) На самом деле, для новичков действительно ничего нет, да и нетворкинг у нас не развит, поэтому все путём проб и ошибок.

От себя добавлю, что Google Firebase в комплекте с GA смотрится вполне прилично.

Ответить
Развернуть ветку
Константин Нелюбин

Спасибо. А я вот всё хочу попробовать. Какие возможности дает, если кратко?

Ответить
Развернуть ветку
Andrey Harchenko

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

Ответить
Развернуть ветку
Константин Нелюбин

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

Ответить
Развернуть ветку
3 комментария

Комментарий удален модератором

Развернуть ветку
Константин Нелюбин

Интересно. А можно примеры?

Ответить
Развернуть ветку
Сергей Токарев

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

Ответить
Развернуть ветку
Константин Нелюбин

Согласен. Я вообще в последнее время от всех игровиков только и слышу что про Юнити. Прямо спасение.

Ответить
Развернуть ветку
Тарас Рогаченко

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

Ответить
Развернуть ветку
Тарас Рогаченко

В действительности на эту тему информацию найти крайне сложно... Даже самые банальные вопросы задавать просто некому. Не должен же я сразу идти в студию разроботки за этим...

Ответить
Развернуть ветку
Константин Нелюбин

Тарас, спасибо. Рад, что информация показалась полезной. Я не думаю, что здесь модно подписаться, стучитесь ко мне в Фейсбук. https://www.facebook.com/profile.php?id=100003469386187

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Константин Нелюбин

Дв просто не влезло. Я всё это расскажу во второй части. Просмотр видео за награду сейчас уже чуть ли не 30-40% дохода в игра. А иногда и того больше. В моих это 30%. Баннеры внизу экрана ооочень малодоходны, поэтому их просто убирают, чтобы не раздражать пользователей.

Ответить
Развернуть ветку
6 комментариев
ОМА CRYPTO

Я думаю если Google воплотит свои задумки осенью, которые анонсировал на конференции Google I/O 2016 https://www.youtube.com/watch?v=OJQch56tb4s&list=PLxZXKy8AjvN8FADF0tVGx9JAlNbeWznUF&index=4 (Константин, там как раз инфа есть про Firebase). То Андроид надо будет поставить в приоритет, но в чём и прелесть кроссплатформы, то что можно выпустить сразу под 3 системы.

Ответить
Развернуть ветку
Константин Нелюбин

Очень надеюсь! На самом деле, Google УЖЕ ИМХО целевая платформа №1. Ещё бы как-то всё таки с поисковой выдачей поколдовали, было бы просто отлично. Я вот уже в следующих релизах установлю Firebase. Посмотрю, что дает и какими плюшками балует. Очень интересно. Посылать нотификации, тест-лаб - уже одно это интересно. Пока не понимаю, как там с оплатой, нужно разобраться.

Ответить
Развернуть ветку
7 комментариев
Максим Буреев

Спасибо за статью. Ещё пара вопросов есть...

1. Можно ли сейчас ограничиться какой-нибудь одной платформой? (если выбирать между - аёс и андроид). Они же вроде щас уже набрали огромные аудитории.

2. В последнее время часто вижу негативные отзывы от разрабов, якобы мобильные маркеты совсем уж стухли в плане заработка. Имеет ли смысла кому-то (если это не разработчик серии GTA) писать своё приложение с целью заработать?

Ответить
Развернуть ветку
Константин Нелюбин

1. Андроид - это 80-85% устройство в России, но где-то 50% денег. Если вы делаете бизнес, то отказываться от одной из платформ неразумно.
2. Имеет смысл любой бизнес, в котором доход больше затрат. "Стухли" - что это означает? Да, в России падение в 2 раза из-за кризиса. Но не только валовый доход определяет эффективность бизнеса.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Константин Нелюбин

"Samsung Appstore (у них бесподобный аудит)" - расскажите. Что вы имеете в виду? Там есть вся статистика? Я, честно говоря, с этим стором не знаком.

Ответить
Развернуть ветку
2 комментария
Michael

Это Гелекси Эпс?

Ответить
Развернуть ветку
13 комментариев
Константин Нелюбин

А про нативные - будет интересно обсудить. Может какие-то конкретные примеры и кейсы появятся, тогда картинка будет более полной.

Ответить
Развернуть ветку
2 комментария
Konstantin Konopko

Нативный Андроид сам по себе лагает регулярно, а вы про кросспл..

Ответить
Развернуть ветку
Константин Нелюбин

Это не про плохого танцора? )) Не всё зависит от Андроид, согласитесь.

Ответить
Развернуть ветку
4 комментария
Дмитрий Диденко

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

Ответить
Развернуть ветку
Константин Нелюбин

Только что Александру Сибиркову в Фейсбуке ответил. Давайте вот сходу:
1. Вы ссылки называете "Трекерами". Я нигде больше такого не встречал, и сначала путаешься, потому что ищешь возможность создать именно ссылку. Это усугубляется п.2.
2. Как только попадаешь на главную страницу, тут же видишь "Добавить приложение". Но приложения добавляются ОЧЕНЬ редко. В 99% случаев мне нужно создать новую трекинговую ссылку (на 1 приложение их создаются десятки, согласитесь), а такой возможности сделать сходу у вас нет. По-хорошему кнопку "добавить приложение" нужно поменять на "добавить трекер". Саму кнопку сделать поярче, я в первый раз очень долго её искал по интерфейсу. Помогите новичкам, акцентируйте внимание на наиболее частых сценариях.
3. Заходя в меню трекеров видишь полупустой список трекеров. Зачем он вообще? Теряешься и пытаешься как-то сориентироваться, вспомнить, который тебе нужен. Выведите сюда сразу показатели на последний месяц (клики, инстоллы хотя бы) и отсортируйте (либо дайте возможность сортировки) по времени создания, активности, партнеру, названию. А ниже можно добавить сводный график по трекерам, он очень помог бы видеть общую картинку. График даже нужно выше списка.
4. Кликаешь на трекер и попадаешь в его настройки. Я в 99% случаев настройки трекера не меняю, но хочу видеть его статистику. Зачем мне по клику на настройку показывать его внутренности? Я их и так вижу уже на сводной странице. Показывайте по клику статистику. Это прямо в замешательство вводит.
5. В продолжение предыдущего пункта, у вас там "скопировать трекер" на странице списка, но без статистики по трекеру она мне бесполезна. У меня их десятки, я не помню просто, какой мне нужен. Приходится прокликивать все (или я не нашел возможности смотреть все в одном месте) есть такая?
6. Потом создаешь трекер. Если я выбрал уже Андроид приложение, почему автоматически не делать селект платформы? То же самое с целевой ссылкой. Она же всегда неизменна, почему не подставлять её сразу после выбора приложения? Зачем выпадающее меню, в котором одна единственная целевая ссылка и так будет всегда?
7. Я не могу создать ссылку без партнера. Если я хочу просто трекинг внутри приложения сделать, то мне нужно обязательно "добавить партнера". Это вообще не понятная формулировка для новичка. Куда добавить? Какого партнера? Напишите "Создать свою трекинг-ссылку" или что-то вроде и сделайте эти кнопки "выбрать партнера" и "создать партнера" равнозначыми. На этом этапе часто как то, так и другое.
8. И под конец нажимаешь "создать", но ничего не создается. Для этого зачем-то нужно ещё и сохранить. И у меня не всегда это выходило, ссылка не работала, что-то было не так, но понять было сложно. Однажды я просто плюнул и сгенерил ссылку в AppsFlyer за 20 секунд. Кнопка "Сохранить" становится бесцветной, как будто неактивна. Рядом с ней кнопка "создать и дублировать". Но я ведь уже создал. Что будет, если нажму? Ещё одна создастся?

Ну вот как-то так ))

Ответить
Развернуть ветку
5 комментариев
Олег Леонов
>Что выпустить первым — iOS или Android

Вы сравниваете совершенно не по тем критериям.
Сравните приложение для таксистов или асфальтоукладчиков и приложение для "модного" журнала.

>Сниженная производительность

Например, длинный список с картинками. Скролите и получаете лаги. Это про phonegap и кросплатформенную разработку.

>Кроссплатформа будет очень дорога в обслуживании

Опять же про phonegap. Можно потратить не один день, в поисках причины на конкретной версии android и webview, почему компонент работает неправильно.
Для крешей сейчас на Android используют Firebase - стоит упомянуть.

Ответить
Развернуть ветку
Artem Shevchenko

или Crashlytics - для крашей

Ответить
Развернуть ветку
1 комментарий
Константин Нелюбин

Не очень понял. Я говорю, что в Плее есть инструменты, которых в Коннекте просто нет. При чем тут типы приложений?

Ответить
Развернуть ветку
al

Кроссплатформа плоха, если вы хотите развиваться в одном темпе с целевой платформой. Новые API приходят во всякие замарины с большим опозданием.

Ответить
Развернуть ветку
Константин Нелюбин

Этот аргумент я как раз привел в статье, как один из весомых. Но опять же. С большим - это с каким?

Ответить
Развернуть ветку
10 комментариев
al

" Это может быть, например, игра или ещё одна соцсеть."

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

Ответить
Развернуть ветку
Константин Нелюбин

Конечно. На Юнити уже 3 игры выпустил. А вы какой информацией располагаете? Давайте свое мнение, обсудим.

Ответить
Развернуть ветку
2 комментария

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Читать все 127 комментариев
null