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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

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

\r\n

Статистика

\r\n

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

\r\n

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

\r\n

\r\n\tНа рынке есть много решений: