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

Главная сложность в разработке приложения – накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

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

---

О базовых продуктовых рисках говорить не буду. Понятно, что если вы не найдете свой product-market fit, то всё остальное уже не будет иметь значения. Поэтому давайте предположим, что вы придумали перспективную идею приложения, сделали грамотный кастдев, изучили рынок и конкурентов, продумали монетизацию, просчитали юнит-экономику и бизнес-модель, наняли толковую команду. Вроде все схвачено… Или нет?

Содержание

1. Выбор фреймворка

2. Устаревание кода

3. Требования стора

4. Видимость в поиске

5. Мобильная аналитика

6. Внешняя аутентификация

7. Адаптивный дизайн

8. Организация тестирования

9. Поддержка версионности

10. Работа офлайн

11. Push-уведомления

12. Перевод и локализация

13. Защита приложения

1. Выбор фреймворка

Ещё до написания первой строчки кода – вы встанете перед судьбоносным выбором: делать приложение нативно под каждую платформу (iOS / Android) или на кроссплатформенном фреймворке?

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

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

Что почитать по теме?

• Кроссплатформенная мобильная разработка: история вопроса

• Больше всех пахала лошадь, но председателем колхоза так и не стала

• Как правильно переходить границу: кроссплатформенность в мобильном приложении

• Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки

• Когда имеет смысл писать кроссплатформенные приложения: появление и исчезновение React Native в Lingualeo

• Новое приложение «Медузы». Почему Flutter?

• Почему Flutter побеждает?

2. Устаревание кода

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

Обновлять приходится всё: фреймворк, SDK, библиотеки, работу с внешними API, поддержку новых версий iOS и Android.

Если не обновить код вовремя – произойдет одно из двух:

• Ваш релиз не пройдет ревью, то есть вы не сможете обновлять приложение.

• С ревью проблем не возникнет, но что-то в приложении перестанет работать.

Кому-то это покажется мелочью – ну что там, код иногда нужно переписать.

Подумайте об этом в таком ключе: вам придется оплатить неделю-другую разработки и не получить вообще никакого business value в продукте. Более того, вы вынуждены отложить все действительно важные продуктовые задачи. И делать такое приходится регулярно.

Что почитать по теме?

• Разрабатывать приложения под Android — словно быть (демонетизированным) ютубером

• В macOS 10.15 более не поддерживаются 32-битные приложения. Что вы можете сделать?

• Уровень Android API, обратная и прямая совместимость

• Кремлевские девойки

3. Требования стора

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

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

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

Например, однажды мы полтора месяца вели переговоры с Apple. Переписывались, созванивались, объясняли, как работает приложение, высылали документ с описанием нашей бизнес-модели… Всё это время мы не могли зарелизиться, а наши пользователи сидели с непофикшеными багами. По итогу пришлось вырезать из приложения функционал, который делал жизнь пользователей проще. Забавно, что приложение жило с этим функционалом уже пару лет и претензий со стороны App Store не было.

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

Что почитать по теме?

• За что Android-разработчики ненавидят Google

• Почему я как разработчик ненавижу iOS

• Как я разочаровался в Google Play

• App Store не позвонит. Или как я сделала своё приложение, но оно не попадёт к пользователям

• Я сделал PWA и выложил в трёх магазинах приложений. И вот что я выяснил

4. Видимость в поиске

Не важно, насколько классное приложение вы сделали, если его никто не скачает. Например, когда я впервые зарелизил свое приложение – оно появилось в выдаче только через 10 дней, на 143 позиции!

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

Но если вам нужен органический трафик – тогда добро пожаловать в алый океан. Просто настроить ASO будет недостаточно, придется придумывать хитрые схемы продвижения. И конкурировать с приложениями, которые уже продвигаются годами.

К тому же, сторы держат алгоритм ранжирования в секрете и он может меняться со временем.

Что почитать по теме?

• Продвижение мобильных приложений: выученные уроки

• Как продвигать мобильное приложение в 2019 году: 4 практических способа + полезные инструменты

• ASO: ранжирование в App Store и Google Play (найди 10 отличий в алгоритмах)

• Как повысить рейтинг приложения в Google Play?

• О том, как выпустить отличное iOS приложение, которое никому не нужно

• Как я слил 1000$ в продвижение игры и что из этого получилось

5. Мобильная аналитика

Аналтика – это всегда непросто.

Google Analytics стремится засемплировать ваши данные, события Amplitude блокируются браузерами пользователей, а в атрибуции каналов сам черт ногу сломит.

Но с мобильной аналитикой всё ещё хуже.

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

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

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

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

Пример решения: как определить, откуда пришел пользователь

Вкратце, вам нужно будет:

• Интегрировать сторонний SDK в свое приложение.

• Вести рекламный трафик не на страницу своего приложения в сторе, а на промежуточную техническую страницу (а уже с неё перенаправлять в стор).

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

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

Что почитать по теме?

• Сравнение аналитических систем для мобильного маркетинга

• Мобильный маркетинг: расхождения в статистике установок

• Переход от Google Analytics к Firebase

• Запуск мобильного ретаргетинга с Appsflyer: настройки, отчеты и ссылки

• Универсальные ссылки: дворец из подводных камней

6. Внешняя аутентификация

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

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

Поэтому приходится прикручивать другие способы входа – через FB, VK, Apple, Google, Telegram. Но это сторонние сервисы, которые живут своей жизнью. А значит, ваша аутентификация может сломаться только потому, что Facebook что-то изменил на своей стороне. А он изменит, не сомневайтесь.

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

Например, Apple заставит вас сделать вход через Apple ID. Только вот на сайте у вас вряд ли был Apple ID. Как связать эти аккаунты? По email? Ок, вы будете запрашивать еще и email во время регистрации в приложении через Apple ID. Но пользователь мог зарегистрироваться в Apple под другим email’ом. Или просто запретил передавать email в настройках.

Тут столько подводных камней, что хватило бы на отдельную статью.

Что почитать по теме?

• Внедряем Sign in with Apple — систему авторизации от Apple

• Использование OAuth и API VK в Go

• Авторизация с помощью Facebook и Vkontakte в одностраничном приложении на Backbonejs + Express

• Авторизация пользователя на вашем сайте через Telegram для Django

• Аутентификация OAuth2 в приложении посредством Google Sign-In. Непрерывный доступ к API Google

7. Адаптивный дизайн

Хочется, чтобы приложение смотрелось прилично хотя бы на актуальных смартфонах. Только вот смартфонов этих тысячи, и отличаются они не только разрешением, но и пропорциями, и плотностью пикселей. А есть еще и особенности конкретных моделей, вроде моноброви у iPhone X.

Кроме того, встречается как «натуральный» Android (например, у Samsung или Google), так и смартфоны, использующие ядро Android + свою интерфейсную обертку (например, Xiaomi). Где-то клавиши навигации аппаратные, где-то виртуальные, а где-то их вообще нет.

Поэтому не думайте, что адаптировать дизайн под весь этот зоопарк – простая задача. Для каждого разрешения нужно:

• растянуть интерфейс и контент под размеры экрана;

• масштабировать изображения без потери качества;

• масштабировать элементы управления, чтобы ими комфортно было пользоваться;

• выдерживать размер шрифтов так, чтобы тексты были читабельны;

• избежать наслоения элементов;

• не дать целевым кнопкам уйти за пределы экрана;

• продумать поведение экранной клавиатуры.

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

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

Что почитать по теме?

• Руководство для дизайнера по DPI

• О размере экрана, пикселя и элемента

• Оптимизация графики для Retina-экранов

• 32 отличия дизайна мобильного приложения под iOS и Android

• «Поясняем за чёлку» в Android P. Что делать с Android Cutout?

8. Организация тестирования

Тестирование приложения заметно отличается от тестирования сайта. Причем не в лучшую сторону. Поэтому если вы планировали, что ваши web QA быстро просмотрят приложение перед релизом и всё будет хорошо – вероятно, вас ждет разочарование.

Вот на что стоит обратить внимание:

• Разнообразие устройств и разрешений.

• Большой разброс версий операционных систем.

• Мобильные механики: мультитач, работа в фоне, аппаратные кнопки, экранная клавиатура.

• Ресурсы телефона: производительность, расход заряда, утечки памяти.

• Плохая скорость интернета или его отсутствие.

• Внезапные прерывания: смс, звонки, разряд аккумулятора.

• Работа push-уведомлений.

Типичная ситуация, когда баг возникает только на 10% устройств. Вы узнаете об этом только из жалоб пользователей. А у вас такого устройства просто нет. Как тогда воспроизвести баг и понять, что удалось его починить? Можно использовать эмуляторы, но они не эмулируют аппаратную часть. Есть ещё фермы устройств, но они тоже не идеальны – например, не позволяют «пощупать» свой продукт.

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

К качеству мобильного тестирования особые требования: в отличие от web, вы не сможете быстро пофиксить баг, если QA его пропустили. Придется снова собирать билд, отправлять его на ревью, ждать эпрув.

Что почитать по теме?

• Что общего у мобильного QA и осьминога

• 7 лучших ферм устройств для тестирования мобильных приложений

• Управление фермой Android-устройств. Лекция в Яндексе

• Гиперкуб. Как мы обеспечили разработчиков тестовыми устройствами и не потеряли их

• Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

• Мобильное тестирование, автоматизация тестирования, тестирование API: с чем нужно уметь работать в 2021 году

9. Поддержка версионности

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

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

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

Нет-нет, постойте, вот вам задачка на подумать: если вы релизите бэкенд в понедельник и в тот же день отправляете билд в сторы – то в Google Play приложение обновится в среду, а в Apple Store – через неделю. То есть у вас невольно получится три разных даты релиза и несовпадение версий фронтенда и бэкенда  – как это вообще должно работать?

Что почитать по теме?

• Версионность веб-приложений

• Версионная миграция структуры базы данных: основные подходы

• Генерируем номер версии и билда на иконке iOS приложения

• Инструмент автоматизации управления версиями

10. Работа офлайн

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

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

Что с этим делать? Как минимум выдать ошибку и объяснить пользователю, что происходит. Как максимум – сделать офлайн-режим или скачивание данных на устройство (как это сделано у Google Maps или 2GIS, например).

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

Что почитать по теме?

• Автономность в первую очередь

• Поиск без интернета. Новая бета приложения Яндекс

• Как мы запустили offline-версию сайта RG.RU

• Переходим В OFFLINE FIRST с использованием Core Data и Managed Document(s)

• Amelisa. Оффлайн и реалтайм движок для React и Mongo

• Оффлайн-режим на iOS и особенности его реализации на Realm

11. Push-уведомления

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

Но прикрутить механику отправки пушей – это только полдела. А вот вторая половина:

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

• Если уведомления отправляются по расписанию – нужно учитывать время и часовой пояс получателя. От разбуженного среди ночи пользователя не ждите слов любви.

• Если пуши отправляются по триггерам – реализация самих триггеров может оказаться трудоемкой задачей.

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

• Вероятно, вам понадобится отдельная логика отправки пушей: очередь, приоритеты, ограничения.

Все вышесказанное будет не особо эффективно, если только 10% пользователей согласятся получать уведомления. Поэтому отдельный квест: как грамотно запросить разрешение на отправку. Ведь если пользователь нажмет «Запретить» – исправить это почти невозможно.

Что почитать по теме?

• 5 ошибок в реализации push-уведомлений для мобильных приложений

• Безопасные push-уведомления: от теории к практике

• Основы успешной реализации push-уведомлений для мобильных приложений

• Пара способов отправить уведомления на смартфон со своего сервера

• Внедряем кросс-платформенные пуш-уведомления: дополнительные возможности

12. Перевод и локализация

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

Локализация почти всегда выглядит простой задачей, и почти всегда это не так.

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

Стоит ли говорить, что перевод это только часть локализации?

Что почитать по теме?

• Локализация приложения за 10 шагов

• Локализация приложений: как мы подружили перевод и разработку

• Локализация мобильных приложений: основные сложности и лайфхаки

• Что разработчику нужно знать о локализации приложения

• UX при локализации приложений: пособие разработчика

• Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist

13. Защита приложения

Если вы делаете приложение попроще, чем Telegram / Monobank / VK – то вряд ли вопрос безопасности не дает вам уснуть. Тем не менее, по моему опыту, даже маленькие приложения ломают.

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

Более наглые ребята могут ломать ваше приложение прямо в сторе. Говорят, что особенно легко это делать в Google Play. Есть разные способы, расскажу, как было у нас.

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

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

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

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

Что почитать по теме?

• Топ-10 уязвимостей мобильных приложений и способы их устранения

• Безопасность данных в разработке мобильных приложений

• Разработчик, помни — трафик твоего приложения смотрят

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

• Безопасность Android-приложений. Лекция в Яндексе

• Двухфакторная аутентификация, которой удобно пользоваться

That’s all Folks!

Мне не хотелось бы, чтобы статья демотивировала тех, кто собрался делать свое первое приложение. Её задача – помочь трезво оценить объем предстоящей работы и показать неочевидные проектные риски. Иногда именно неверная оценка сложности проекта губит хорошие продукты.

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

Как работает синергия рисков

Например, вы заметили, что доход приложения падает.

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

Окей, вы срочно чините баг, отправляете билд на ревью и… его отклоняют.

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

История затягивается, и всё это время пользователи отваливаются, доходы падают, приложение теряет позиции.

По отдельности эти риски не представляли бы такой угрозы.

---

P.S. Я в общих чертах обозначил, на что стоит обратить внимание. Но чтобы разобраться в любой из этих тем – лучше почитать специализированные статьи. А если вы помните хабростатью, которая хорошо раскрывает любой из перечисленных вопросов – поделитесь ссылкой и я добавлю её в пост.