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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That’s all Folks!

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

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

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