Как я потратил полгода на обновление приложения и потерял 10 тысяч пользователей

Всем привет! Меня зовут Денис Кравцов. Я разработчик приложения Smart Timetable — расписания для школьников, студентов и преподавателей.

Мне как начинающему iOS-разработчику после изучения теории и примеров захотелось создать маленькое приложение для публикации в сторе. Самым простым и очевидным приложением обычно является тудушка (от англ “todo”). Я не стал нарушать эту традицию.

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

Поскольку в iOS-разработку я пришел из веба, то первая версия очень напоминает веб-страницу с формой для ввода данных. Профдеформация налицо :))

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

C 2018-го по март 2019-го было несколько итераций с добавлением уведомлений, четной и нечетной недель, поддержки Apple Watch и прочих мелочей. Несмотря на простоту приложения, за полтора года набралось 50 тысяч пользователей.

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

Летом 2019 года появилось желание сделать нечто большее, чем простую таблицу. Была изучена масса комментариев у приложений-конкурентов как в AppStore, так и в GooglePlay. Собрался список фич, которые нужны пользователям, но которых нет среди других приложений или они есть в зачаточном состоянии.

Что получилось собрать:

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

Кроме выходных расписание также переносят праздничные дни. Расписание кастомной недели вычисляется так: пн(1)-вт(2)-ср(3)-чт(4)-пт(1)-сб-вс-пн(2)-вт(праздник)-ср(3)-... и так далее. Такие расписания, как оказалось, очень популярны в школах США и Канады. Их называют rotation schedule.

На реализацию всех хотелок у меня ушло полгода. Полгода, Карл! Почему так? Этому есть несколько причин:

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

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

Когда стало понятно, что в сентябре запуск никак не состоится, запуск был перенесен сначала на ноябрь. Потом на декабрь. А потом на 31 января.

До ноября 2019-го задачи заносились в Redmine, а также в чат Telegram. Гораздо веселее дело пошло в конце ноября, когда задачи стали разбиваться на спринты (мы их назвали билдами) и заноситься в Trello. На каждый билд отводилась одна неделя.

Начали мы с билда 43, поскольку текущая версия приложения на тот момент была 4.3. И так уж совпало, что билд 50 пришелся на релиз версии 5.0. Теперь номер билда это фактически версия приложения после деления на 10. На момент написания статьи в работе билд 58 для версии 5.8.

От некоторых задач пришлось отказаться и отложить их на «после запуска». Среди таких задач были версия под iPad, виджеты на циферблат Apple Watch, экспорт расписания.

Выяснилось, что валидация чека для проверки активности подписки работает как-то не так. Пользователи сразу начали жаловаться на то, что после оплаты Pro-версия всё так же недоступна. На бета-тестерах это отражалось, но в бета-среде не всё можно протестировать. Например, нельзя протестировать отказ от подписки/покупки. Ну раз написано, что должно работать, то в продакшене точно заработает. Ага, конечно. Версия 5.0.1 содержала багфиксы по проверке чека.

Поскольку я переписывал приложение с нуля, с принципиально новой функциональностью, создавать «мост» между старой и новой версиями не планировалось. Это означало, что расписание не будет перенесено. Кому понравится, что его данные после обновления слетят. Мы (разработчик, ASO-шник и тестировщик) морально готовились к этому негативу со стороны пользователей.

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

Из-за того, что прежнее расписание не было сохранено, негативные оценки и отзывы, поступающие сразу после обновления приложения, повлияли на рейтинг. Отзывы и оценки друзей не помогли :). Средний балл по миру с 4,7 упал до 4,5, по России с 4,8 до 4,6. Через некоторое время ситуация выровнялась и средний балл поднялся до 4,6 и 4,7 соответственно. Отзывы в основном касались резкой смены интерфейса и потери расписаний.

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

Через некоторое время страсти поутихли и отзывы стали положительными.

Спасибо пользователям за отзывы.

Впереди еще был огромный объем работы: горизонтальная ориентация расписания на iPhone, версия под iPad, приложение под Apple Watch, Web-версия расписания. На момент выхода статьи всё это реализовано, но для запуска 5.0 решено было этого не делать для экономии времени. На доработку всего запланированного после запуска ушло еще два с половиной месяца.

Сложнее всего оказалось сделать версию под iPad и экспорт через PDF. Если с iPad всё более-менее ясно, то PDF — это рисование точек и линий по координатам. Кто занимался подобным в универе, тот в теме. Такое рисование лишено привычных constraint и вертикального выравнивания текста. Нужно вычислять предполагаемую высоту текста и делать отступы внутри контейнера.

1. Валидация чека

Не работает так, как это описано в документации Apple, а именно: чек то есть, то его нет, то покупки не сразу появляются. Гуглил на эту тему и похоже, что в iOS 13 что-то изменилось или я что-то делаю не так.

Решение — сохранение данных транзакции и периодическая проверка чека. Валидация чека актуальна, если у вас есть подписки. У меня Pro-версия доступна по подписке $0,99 в месяц или после покупки за $4,99. Для обычных покупок проще и быстрее хранить лишь признак оплаченной транзакции. Но здесь есть нюанс — без проверки чека вы будете предоставлять премиум-доступ даже в том случае, когда пользователь вернул средства от Apple.

2. Лимит на количество уведомлений в очереди центра уведомлений

Я ожидал, что переполнение очереди вызовет ошибку. Но это не так. Можно добавить хоть сотню уведомлений и все они будут добавлены со статусом success. После лимита в 64 записи все последующие будут перезаписывать существующую очередь. Выход: при каждом входе в приложение пересобирать уведомления на ближайшие N событий. А ведь когда расписаний несколько, то и количество уведомлений растёт как на дрожжах.

3. Расписание не содержит дату, а лишь время и день недели

Решение в том, чтобы начинать перебор дней недели от текущей даты с подстановкой времени занятий. Регулярность уведомления isRepeat=true не подходит, так как занятие можно однократно удалить или добавить в произвольный день.

4. Синхронизация данных

Поскольку мобильная разработка подразумевает работу приложения в онлайне и офлайне, вопрос синхронизации не так прост, как кажется. Не использовал iCloud, потому что есть планы кросс-платформенной синхронизации между iOS, Android, вебом. Для каждой модели добавлены поля deleted, ts, чтобы понимать, когда что удалено, изменено, добавлено. На основании этих данных делаю merge данных при появлении сети. Что обновлено позже, то имеет приоритет. Если на любом шаге было удаление, то все остальные изменения игнорируются.

5. Несколько расписаний

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

6. Отказ Firebase в некоторых регионах

Пользователь из Крыма пожаловался на то, что по Wi-Fi не может отправить расписание. Хотя по сотовой связи всё ок. Поддержка Firebase ответила, что есть некий список регионов, который находится под санкциями. Был удивлен тем, что Беларусь по какой-то причине также в этом списке. Полный список можно посмотреть здесь.

#приложения #ios