Интересная идея, хорошая команда и перспективная бизнес-модель не спасет вас от подводных камней в разработке. Мы собрали 9 самых популярных проблем, о которых стоит подумать прежде, чем заказывать разработку приложения.
1. Выбор фреймворка
Сразу посчитайте, что для вас важнее: использовать все возможности платформы и получить быстрое легко масштабируемое приложение или сделать кроссплатформенное решение на 30% дешевле.
Заказывать разработку приложения отдельно под iOS и Android всегда дороже, но надежней. Это как автомобиль заводской сборки: сел и поехал. Если использовать кроссплатформенный фреймворк, приложение получится дешевле, однако пользователям придется подстраиваться под особенности и ограничения функционала.
Определитесь с приоритетами «на берегу». На стадии разработки отмотать назад не получится, а после первого релиза кусать локти будет поздно.
2. Устаревание кода
Актуальность кода нужно поддерживать. Вовремя и регулярно. Если этого не делать:
- Приложение не пройдет очередную проверку маркета. Тогда вы лишитесь возможности обновлять приложение.
- Рано или поздно в приложении появятся баги, которые все равно придется фиксить.
Устареть может любая технология, ведь постоянно вводятся новые стандарты, которым нужно соответствовать. Заказывая разработку приложения сейчас готовьтесь, что придется оплачивать дополнительные недели правки багов и модернизации кода потом. Это займет время и деньги — учитывайте их в планах и бюджете.
Если не готовы тратиться на поддержку приложения, откажитесь от разработки сразу. Сэкономите пару миллионов.
3. Требования стора
Маркеты проверяют каждое обновление приложения. Иногда это происходит чисто формально, но нужно готовиться возможному отклонению релиза. Если так случается, выход один — реагировать на претензии сторов и исправлять продукт с учетом их требований. Либо доказывать свою правоту. Последнее сложнее и дольше — говорим по опыту.
Учитывайте, что правила App Store и Google Play постоянно меняются и дополняются. Какие-то изменения могут никому не нравиться и быть объективно неразумными, но если хотите быть в сторах, придется их учитывать.
Здесь как с поддержкой — заложите резерв на форс-мажоры, связанные с правилами App Store и Google Play.
4. Видимость в поиске
Чтобы пользователи узнали о вашем продукте, он не должен болтаться на дне выдачи. Нужно разработать и реализовать стратегию продвижения. Одной настройки ASO не хватит. При этом магазины приложений не раскрывают алгоритмы ранжирования. Придется тестировать и экспериментировать. Разумеется, эту проблему можно игнорировать, если вы привлекаете только платный трафик.
Предусмотрите маркетинговое продвижение приложения, если только это не корпоративный продукт.
5. Мобильная аналитика
Мобильная аналитика сложнее веб-аналитики, потому что сложно понять, откуда пришел пользователь. Когда человек скачивает ваше приложение, вы не узнаете, нашел он его в выдаче, перешел по рекламной ссылке в партнерском блоге или использовал QR-код. Utm-метки не работают, из-за чего возникают сложности с реферальными ссылками.
Посмотрите, какие варианты мобильной аналитики можно использовать на старте. Желательно из простых и доступных. Потом можно заморочиться сложным продуктом с данными по всем разрезам. Для запуска достаточно базового функционала.
6. Тестирование
Тестировать приложение тоже сложнее, чем тестировать сайт. Во-первых, на рынке много устройств с разными разрешениями. Во-вторых, далеко не все пользуются последними версиями iOS и Android.
А ещё при тестировании нужно проверить:
- Все основные механики: фоновую работу приложения, работу мультитача, аппаратных кнопок, экранной клавиатуры,
- Как ведёт себя приложения при плохом интернете или вовсе без него,
- Как работает приложение на устройствах с разной производительностью, сколько заряда тратит, сколько забирает памяти.
Заказывая разработку приложения, сразу закладывайте время на тестирование. Обязательно. Иначе есть риск устроить торжественную презентацию продукта и пройти через адовы муки факапа, потому что приложение просто не запускается.
7. Работа офлайн
До сих пор полно мест, где связь нестабильная или её вовсе нет. Если для работы приложения необходим интернет, продумайте, как будет вести себя приложение в офлайн режиме. Может быть сообщить пользователю об ошибке и порекомендовать возможное решение? Или добавить офлайн режим, с возможностью сохранения данных на смартфон? Или разработать систему синхронизации с сервером?
Продумайте этот момент до разработки, потому что почти половина пользователей предпочитают приложения, работающие либо вообще без интернета, либо с опцией синхронизации с сервером.
8. Push-уведомления
Пуши — эффективный канал взаимодействия с пользователями. Они могут напоминать человеку зайти в приложение, сообщать о специальных предложениях, отправлять персонализированные сообщения и т.д. Но чтобы механика отправки уведомлений работала правильно, вам предстоит учесть:
- Каким способом будут отправляться push-уведомления? В определенное время, на основе триггеров или вручную? Возможно, придется комбинировать все способы.
- Если пуши приходят пользователю по времени, учитывайте его местное время и часовой пояс. Если человек проснётся ночью от уведомления из приложения, вряд ли это сыграет вам на руку.
- При отправке уведомлений вы используете триггеры — будьте готовы к сложной реализации такой механики. Поскольку несколько триггеров могут сработать одновременно, или триггер может сработать вместе с пушем по времени. Большое количество пушей будет раздражать пользователя. Со временем, он заблокирует уведомления, или вовсе удалит приложение.
Сразу продумайте логику отправления уведомлений, чтобы приоритетами и ограничениями решить проблему спама до того, как о ней сообщат пользователи.
9. Перевод и локализация
Локализация — это не просто перевод. Как минимум, придется дорабатывать архитектуру базы данных для поддержки мультиязычности. Если приложение будут скачивать в разных странах, с приложением без локализации вы получите негативные оценки и отзывы.
Локализация не бывает дешевой, поэтому сразу решите, вы готовы принять негатив от пользователей из других стран или планируете изначально проектировать приложение с локализацией.