На чем собрать мобильное приложение без кода — топ-3 конструктора с примерами приложений
Самый популярный вопрос среди начинающих зерокодеров — можно ли собрать мобильное приложение без программирования. Расскажем, с помощью каких инструментов это можно сделать, чем они отличаются и сколько это стоит.
Существует три подхода к созданию мобильных приложений:
Инструменты зерокодинга уже могут покрыть большинство задач бизнеса. И вместо того, чтобы изобретать велосипед, можно за несколько дней запустить MVP или проверить гипотезу с минимальными затратами. А если в запасе хотя бы пара недель — то и запилить полноценное приложение. Решения на зерокодинге можно собирать в одиночку — вся инфраструктура предоставляется платформами и не надо дополнительно тратиться на хостинг, администрирование серверов и т.п.
При этом обычная разработка затянется на 3−6 месяцев и съест до миллиона рублей — если работать с фрилансером или скромной региональной студией.
Чтобы быть в курсе новостей зерокодинга, присоединяйтесь к телеграм-каналу «Зерокодер» и чату «Я — зекрокодер».
Самые мощные и популярные инструменты мобильной разработки без кода — Adalo, Glide и Bubble. С их помощью можно создать и опубликовать мобильное приложение. Они бывают трех типов:
Мобильная версия сайта — сайт в интернете, адаптированный под экраны смартфонов. Это самый «бесправный» тип приложений: всегда нужен интернет, пуши можно включать только в браузере, постоянно на виду элементы навигации браузера.
PWA (Progressive Web Application) — когда мобильная версия сайта устанавливается на смартфон как приложение. Из плюсов — не надо поддерживать две кодовые базы, под iOS и Android, приложение всегда «обновлено» до последней версии, можно работать с некоторыми нативными функциями смартфонов. Например, отправлять пуши, устанавливать ярлык на экран, элементы навигации браузера не мешают (их просто нет). такие приложения умеют создавать и Bubble, и Adalo, и Glide.
Нативные — когда приложение публикуется в официальных сторах. В Adalo уже встроена такая функция, а приложения на Bubble можно обернуть в специальный контейнер и тоже опубликовать в Google Play и App Store. Нативные приложения позволяют работать со всеми функциями телефона: камерой, микрофоном, GPS, контактами, файлами, акселерометром, push-уведомлениями, памятью девайса, адаптивной версткой — всё, как в обычном коде, только без кода.
Glide — платформа для создания мобильных приложений без кода. Лучше всего функции сервиса описывает девиз «Создавайте приложения из Google Sheet за пять минут, бесплатно». Glide-приложения нельзя загрузить в сторы, но можно опубликовать в интернете как PWA. Платформа отлично подходит для создания простых приложений и MVP — много готовых симпатичных шаблонов, понятные интуитивные настройки.
Adalo — nocode-платформа для создания веб- и мобильных приложений, которые можно публиковать в App Store, Google Play или в интернете как PWA. Новая версия раскатывается в сторы прямо из личного кабинета на платформе, публикуется тоже оттуда (но нужен аккаунт в AppStore и Google Play). Adalo позволяет создавать приложения в интуитивно-понятном интерфейсе методом drag’n’drop из готовых или кастомных дизайн-шаблонов. Эта платформа мощнее Glide и на ней можно собирать более сложные приложения.
Bubble — одна из самых продвинутых визуальных сред программирования для создания веб-приложений. На нем можно собирать настольные или адаптивные веб-приложения для любого размера экрана.
Bubble позволяет проектировать сложную бизнес-логику — это настоящий комбайн. Приложения на Bubble нельзя выкладывать в сторы напрямую, но есть обходные пути — обернуть их в специальный контейнер и после этого опубликовать в маркетплейсах от Apple и Google.
Разработка приложения «под ключ» — сложный процесс, в котором участвует целая команда специалистов. Программисты пишут бэкенд и фронтенд, дизайнеры создают «человеческий» UX/UI и вкусную картинку, тестировщики ищут ошибки, проджекты управляют всем процессом, лиды — командами, эккаунты общаются с клиентами. И каждый не просто просиживает штаны, а действительно работает и нужен.
Сколько денег возьмет за разработку веб-студия и сколько времени потратит, зависит от сложности проекта и имиджа компании, но в среднем — от 500 тыс. до 5 млн рублей, а средний срок разработки — 4−6 месяцев (по сведениям с Хабра, DTF и Appinventive). Сложные приложения легко могут стоить дороже 10 млн рублей и пилиться больше года — особенно если поджимают сроки или подрядчик входит в какой-то рейтинг вроде Теглайна. И всё это без учёта поддержки, обновлений, продвижения и возможных проблем с масштабированием и доработками.
Nocode-разработка обходится дешевле. Например, Сергей Горелов в одиночку собрал полнофункциональное приложение для фитнес-клуба за пару недель — такое же приложение обычная студия будет разрабатывать около полугода и возьмёт за работу 700−800 тысяч рублей.
А Евгений Спорыхин из nocode Hero вместе с WeLovEnocode запилил карьерный трекер с геймификацией на Bubble. Вместе с детализацией техзадания, доработками, дополнительными функциями и пятью итерациями по дизайну (клиент не совсем понимал, какой он хочет видеть визуальную составляющую) это заняло три месяца и обошлось заказчику примерно в 700 тысяч рублей.
Аналогичная работа «в коде» длилась бы гораздо дольше, а заказчик отдал бы не меньше 4 млн рублей. При этом первую полнофункциональную версию запустили уже через 2 недели — всё остальное ушло на доработки дизайна и добавление новых идей клиента.
Да, у мобильных приложений на зерокодинге пока есть некоторые ограничения: например, чтобы сделать массовый сервис с трафиком в десятки миллионов человек, когда критичны скорость работы и премиальный дизайн, придется создавать свое решение, нанимать программистов или отдавать разработку на аутсорс. А вот первые версии такого продукта — особенно MVP — можно собирать и без кода. Приложения на несколько десятков или сотен тысяч пользователей nocode-платформы также выдержат без проблем.
Снижение стоимости мобильных приложений неизбежно привлечет массовую категорию новых клиентов — теперь приложение может себе позволить даже скромный ИП-шник или владелец пары овощных киосков.
Игорь — профессиональный программист. Как-то раз ему понадобилось выполнить техническую задачу за пару дней — так он вошел в зерокодинг. Сначала автоматизировал на Integromat, потом перешел на Glide. А в пандемию он назерокодил приложение для обучения макияжу MAKE — помогал жене перевести бизнес в онлайн.
Игорь освоил Glide за три дня, еще 4 дня делал структуру приложения. Дольше всего вносил список из 400 продуктов — это заняло 2 недели😂 Приложение интегрировано с ЮKassой, Integromat и GetCourse, можно выбрать свой цветотип, форму лица и глаз, найти инструменты и средства для макияжа, а также получить советы — где их лучше купить, чтобы не попалась подделка.
Когда пользователь открывает приложение, система опознает его: если в Google-таблицах Access не равен Yes и нет отметки trial, то подписка неактивна и выводится экран оплаты. После оплаты подписки в Integromat запускаются две цепочки: первая — для уже зарегистрированных пользователей. Она обновляет запись об оплате в Google-таблице в строке пользователя. Вторая — для новых пользователей. Она создает новую запись в талице.
Если пользователь оплатил подписку с помощью банковской карты, информация о ней сохраняется. За 3 дня до окончания подписки пользователя предупредят о предстоящем списании. После автооплаты система пришлет результат — успешно прошло списание или денег на карте не оказалось. Эта логика собрана на GetCourse.
Запуск топ-приложения в одиночку, бесплатно и без кодинга (ну почти)
Как выучить неправильные глаголы английского, если ты продуктовый менеджер?
Очевидно, сделать продукт для их изучения.
Так я и поступил. Пилил приложение в одиночку, по вечерам, после основной работы. Путь от сырой идеи до релиза занял месяц. Еще месяц ушел на то, чтобы вывести приложение на первые места стора по всем ключевым запросам.
Как это было, с чем столкнулся и какие выводы сделал – читайте под катом.
Вообще-то мне хотелось просто подучить неправильные глаголы.
Но, установив десяток приложений из топа стора, я так и не нашел ничего подходящего. Приложения были перегружены рекламой, неудобными интерфейсами и мудреными механиками. Многие сразу требовали заплатить им денег.
Посмотрев на все это безобразие, я невольно задумался – а что мешает сделать простейшее приложение самому? Механика несложная, а популярных irregular verbs всего штук 100…
Поэтому я взялся за ручку-блокнот и сделал черновой набросок основных экранов приложения. Получалось симпатично.
Так приложение выглядело на бумаге
Ограничения
Я старый солдат и знаю, что когда придумал продукт мечты – важно отсечь лишнее и оставить только ключевой функционал. Иначе есть риск попросту не закончить проект. Особенно если делаешь его в одиночку.
Классика инди-проектов
Поэтому в первую версию я заложил всего 2 фичи:
список глаголов, чтобы познакомиться с ними;
тренировки глаголов, чтобы закрепить их в памяти.
Кроме того, я решил, что приложение будет:
только под Android;
без адаптации под планшеты;
без подстройки экрана под разворот телефона;
работать без сервера.
В дальнейшем я неоднократно сказал себе «спасибо» за эти ограничения. Впрочем, все мы грешны. Поэтому в финальной версии были уже и пуш-уведомления, и геймификация, и статистика обучения. Но давайте обо всем по порядку.
Варфреймы
Скетчи на бумажке — это хорошо, но нужно детально продумать путь пользователя в приложении. Какие у него будут задачи и как он их решит?
Например, список слов. Что там будет? Только 3 формы неправильных глаголов? Но люди, которые учат глаголы, наверняка не знают всех переводов. А нужна ли им транскрипция? А озвучка? А прогресс изучения каждого слова? А возможность скрывать изученные глаголы?
Тут легко нагородить лишних механик или, наоборот, упустить что-то необходимое. Поэтому важно иметь вижн продукта.
Мой вижн звучал примерно так:
Приложение ориентировано на начинашек и должно полностью закрывать их потребность в изучении неправильных глаголов. Но делать это предельно просто и без занудства.
Не вдаваясь в детали, расскажу про 2 инсайта, которые я поймал в процессе прототипирования:
1. Горизонтальная ориентация
Изначально я представлял вертикальное приложение.
Это же привычно, плюс можно держать телефон одной рукой. Но особенность неправильных глаголов в том, что нужно отображать три их формы. А еще перевод, прогресс, озвучка… В вертикальном формате получалась какая-то каша.
Зато в ширину всё помещалось без проблем. Поэтому пришлось переделать все варфреймы под горизонтальную ориентацию.
Варфрейм достаточно точно отображает будущий интерфейс
Я думаю, это хорошая практика – не делать слепо «как у всех» или «как принято». А, наоборот, учесть особенности своего продукта. Так список глаголов мог бы быть слабой частью моего приложения, но стал преимуществом.
2. Отказ от клавиатуры
Я планировал, что в одной из тренировок будет ввод с клавиатуры. Надо же студенту запомнить, как пишутся глаголы, верно?
Но клавиатура ломала пользовательский опыт:
остальные тренировки сводились просто к выбору варианта, а тут такое усложнение;
в клавиатуре слишком много отвлекающего: переключение языков, знаки, цифры;
при выезде клавиатуры нужно как-то смещать или перекрывать контент.
Конечно, можно было сделать собственную, сокращенную клавиатуру. Но мне хотелось предельной простоты управления. Поэтому клавиатурную тренировку я заменил другой, похожей: собрать глагол из букв, перемешанных в случайном порядке.
Тренировка «Собери глагол по буквам»
Реализация
Итак, у меня было 2 пакетика варфреймов, пинта чистого энтузиазма и персональная лицензия на Construct 2. Не то чтобы это был необходимый запас для создания приложения, но выбирать не приходилось – ведь я не разработчик и современным языкам программирования не обучен.
Вообще Construct – это конструктор игр, позволяющий делать игры условно «без программирования». Вся логика строится на интерактивных объектах и событиях «если …, то …». По итогу в моем проекте получилось 322 таких события (это около двух тысяч строчек кода).
Но главная фишка Construct – возможность экспортировать готовый проект на множество платформ, в том числе на Android и iOS.
Уточню, что я неплохо знаком с этим конструктором. Собственно, персональную лицензию я получил, заняв призовое место в конкурсе игровых разработчиков Construct 2.
Немного о конструкторе
Конечно, возможность делать игры «без программирования» – не более чем маркетинговая замануха. Ничего серьезного так сделать не получится.
Но если с алгоритмическим мышлением у вас все в порядке, то Construct дает комфортную среду разработки. Здесь и переменные, и функции, и циклы, и массивы, и всякое такое прочее. Думаю, ближе всего это к визуальному программированию.
Пример кода, который отвечает за переключатели на экране настроек
Если стандартных возможностей конструктора не хватает – можно использовать JS-вставки. Например, я так делал для определения дня года.
Функция Construct на основе JS-кода
Еще один момент, который сильно облегчил и ускорил разработку, – возможность в реальном времени проверять результат. Это происходит так: я запускаю проект на компьютере, захожу на локальный хост из мобильного браузера и сразу вижу полноценное рабочее приложение на экране смартфона. Очень удобно.
Организация проекта
Постараюсь не углубляться в специфику Construct, но расскажу вкратце, как устроен проект.
Он состоит из лейаутов и списков событий. Для каждого экрана приложения я использовал собственный лейаут и список событий. Плюс в отдельном списке событий вел документацию по массивам, чтобы не забыть – что где лежит.
Структура проекта
Базу данных с глаголами, переводами и транскрипциями хранил в обычной табличке Excel. Загружал ее как JSON при запуске приложения. В самом приложении были массивы, отвечающие за статистику обучения и пользовательские настройки. Все изменения массивов сохранял в Local Storage смартфона.
Интересно, что бэклог проекта я вел просто в текстовом файле. И то, занялся этим в самом конце разработки – просто чтобы ничего не упустить. Большую же часть приложения сделал вообще «из головы». Это один из примеров запуска продукта без ТЗ, о которых обещал рассказать в прошлой статье.
Уточню, что код я достаточно подробно комментировал, иначе сам бы в нем быстро запутался.
Дизайн
То есть продукт должен быть, прежде всего, удобным. А красоту можно и позже навести.
Но, конечно, мне хотелось, чтобы приложение выглядело более-менее прилично и современно. Поэтому начал я со стандартного варианта: минимализм, flat design, бледно-голубые оттенки, вот это всё. Учитывая, что сам я не дизайнер, – это беспроигрышный вариант.
Но, поработав над приложением какое-то время, я задумался: «Какого черта? Я же делаю некоммерческий продукт для души. Зачем мне очередной клон Facebook с гаммой хирургического кабинета?». И перекрасил все в теплые ламповые цвета. А войдя в кураж, добавил ещё и лиса в шляпе, чтобы у приложения было узнаваемое лицо.
Учитывая, что Construct – все-таки игровой движок, я не удержался и сделал в главном меню анимированный фон с эффектом параллакса. Это не типично для обучающих приложений, поэтому должно было вызвать небольшой вау-эффект.
Стартовый экран с эффектом параллакса
Дизайн готовил в Adobe Illustrator – где-то с нуля, где-то на основе бесплатных векторных стоков. Векторная графика удобна, когда не умеешь рисовать: можно тягать точки, пока результат тебя не устроит. Таким макаром, например, я сделал заглавную иллюстрацию для этой статьи.
Сборка билда
Сборка билда под стор – тот еще головняк. Конечно, потом привыкаешь и делаешь все на автомате. Но в первый раз хотелось всё бросить.
Вот обобщенный порядок действий:
экспортировать готовый проект из Construct в формат Cordova;
с помощью Adapter сбилдить проект Cordova в apk-файл;
сгенерировать уникальную подпись разработчика;
с помощью Apk-signer подписать apk-файл;
с помощью Apk-signer верифицировать и выровнять apk-файл (что бы это ни значило);
залить готовый билд в стор;
а в первый раз нужно ещё установить и настроить все эти программы и библиотеки.
Самое забавное, что это – простой способ. Он считается аморальным. Есть еще «правильная сборка», которая предполагает древние языческие ритуалы и компиляцию через консольные команды. Кому интересно – вот видеоинструкция.
Когда делаешь приложение в конструкторе игр
Конечно, для меня это всё – темный лес. Я же продакт, у меня лапки!
Как пользователь Construct я хотел бы, чтобы компиляция делалось одной кнопкой «Превратить проект в готовый apk-файл». Наверное, тут Construct сильно уступает «настоящим» средам разработки? Или там такая же морока? Кто в теме, напишите в комментариях, пожалуйста.
Тестирование
Проверялось приложение вручную. Для этого я:
собирал билд и прокликивал его на телефоне;
открывал проект в окне браузера на ПК и тестировал приложение на основных мобильных разрешениях;
сбрасывал тестовый билд друзьям для проверки на других устройствах;
добавил в настройках возможность полного сброса прогресса.
Релиз в Google Play
Должен признаться, Google, я разочарован.
Я привык, что продукты Google для широкой аудитории (почта, поиск, карты, переводчик, гуглдоки) – шикарны. Но когда речь заходит о профессиональных инструментах – все очень-очень плохо.
Достаточно сравнить Google Analytics и Amplitude, чтобы понять, насколько отстал Google.
Google уже не торт
Та же история и с Google Play Console для разработчиков. Кажется, ее делали с похмелья какие-то джуны. Я не понимаю, как компания с неограниченным бюджетом может делать настолько запутанные и нелогичные интерфейсы. А почитайте, что пишут в отзывах про их приложение. Жуть.
Не буду утомлять вас деталями, но благодаря «великолепно» спроектированной Google Play Console я зарелизил свое приложение… случайно! Причем Google не позволяет отменить релиз. Позже я выяснил, что многие столкнулись с такой же проблемой. Повезло, что мое приложение было в приличном виде на момент релиза.
Исторический момент
В общем, тут совет такой: будьте осторожны при заливке билда через Google Console, а лучше потренируйтесь сначала на тестовом приложении.
Проблемы
Как говорят в народе: «Скоро статья пишется, да не скоро билд эпрувится». И действительно, в процессе работы над приложением я столкнулся с рядом проблем. Вот самые неприятные из них:
1. Адаптивность дизайна
Чтобы приложение смотрелось адекватно на любых экранах, приходилось:
масштабировать интерфейс согласно разрешению;
закреплять элементы относительно края экрана;
рассчитывать позицию кнопок на основе ширины и высоты видимой области;
проверять все изменения адаптивности на десятке ключевых разрешений.
И это всё равно не решает вопрос на 100%.
Впрочем, результатом я горжусь – приложение смотрится адекватно даже на телефонах, которых ещё не существовало на момент релиза.
2. Работа без аналитики
Как продуктовому менеджеру, мне очень некомфортно работать без аналитики. Может и есть какой-то способ ее подключить к проекту Construct, но простого решения я не нашел. Поэтому пришлось делать приложение фактически вслепую, полагаясь только на свой вижн и экспертизу.
3. Отсутствие сервера
В принципе, Construct позволяет взаимодействовать с сервером. Но для этого нужен бэкенд-разработчик и хост. Так что решение делать игру без сервера было верным. Тем более, это позволило приложению запускаться локально на смартфоне и работать офлайн.
Но проблема в том, что без сервера нельзя организовать взаимодействие между пользователями или собрать общую статистику по ним. Ну и при чистке Local Storage весь прогресс обучения потеряется.
4. Неполный контроль
Конструктор упрощает разработку, это правда. Но обратная сторона этого решения – невозможность исправить низкоуровневую техническую проблему, если таковая возникнет.
Например, несколько пользователей пожаловались, что в приложении нет озвучки. Причем после перезагрузки она появилась. Я догадался, что звуки просто не успевают прогрузиться. И все, что я смог сделать, – это искусственно увеличить время загрузки приложения. Хорошо, что это помогло. Иначе у меня не осталось бы инструментов, чтобы исправить проблему.
5. Планшеты
Как у разработчика у меня может быть 100500 причин, почему я не хочу делать поддержку планшетов. Например:
моя целевая аудитория не использует планшеты;
мой продукт не подразумевает использование на планшете;
у меня маленькая команда и нет ресурса на планшетную версию;
я хочу обкатать продукт на мобайле, а потом уже делать версию для планшета.
Но Google не позволяет отсечь планшеты – ни при установке приложения, ни в рекламе.
Результат предсказуем – владельцы планшетов качают приложение, разочаровываются, ставят низкие оценки. Спасибо, Google.
Продвижение
Итак, спустя месяц разработки, я зарелизил приложение.
Жду день, жду второй… В выдаче стора оно не появляется. Почитал на форумах, что индексироваться может до недели. Ну что поделать, жду неделю. Ни-че-го.
Google, само собой, даже не пытается сделать этот процесс прозрачнее для разработчика.
Наконец, спустя 10 дней, приложение появляется в выдаче… на 143 позиции!
Первая реакция на появление приложения в выдаче
Делать нечего, пришлось заняться продвижением:
прошу друзей установить приложение и поставить ему 5 звезд;
полностью переписываю ASO-текст, включая туда максимум релевантных ключевых слов;
перерисовываю скриншоты для стора, делая их симпатичнее;
размещаю ссылку на приложение на нескольких ресурсах вроде 4PDA;
отвечаю на все комментарии пользователей, иногда использую ключевики в ответах;
делаю пробную закупку рекламы Google Ads (получилось недорого, порядка 5 центов за установку, всего потратил около 20$);
правлю баги и выкатываю новые версии – чтобы стор видел, что приложение живое и дорабатывается;
в самом приложении делаю страничку с просьбой оставлять оценки-отзывы.
Чтобы отслеживать позиции приложения по разным ключевикам – регистрируюсь в сервисах AppFollow и ASODesk. Первый дает больше бесплатных возможностей, второй шлет письма с отчетами о позициях приложения.
Итоги всей этой движухи спустя примерно месяц:
Отчет ASODesk
На самом деле, я вижу ряд причин, почему так получилось:
Ниша специфическая. Приложений, заточенных под изучение неправильных глаголов, не так много. То есть конкуренция не большая.
Я выбрал довольно удачное название – в него удалось впихнуть важные ключевые слова.
Первое время рейтинг приложения зашкаливал – там были сплошные пятерки, несколько четверок и ни одной оценки ниже.
Рекламная кампания была небольшой, зато своевременной – показала стору хорошую динамику скачиваний.
Приложение достаточно удобное, бесплатное, работает офлайн, в нем нет рекламы – думаю, это положительно сказалось на поведении пользователей и их оценках.
Удержание пользователей
Так как аналитики у меня не было – пришлось полагаться на свой опыт. Для удержания пользователей я решил использовать геймификацию и пуш-уведомления.
Геймификация
Проблема всех образовательных продуктов – мотивация студента. Поэтому нужно было дать студенту какую-то понятную ежедневную цель. А в идеале – еще и причину, чтобы вернуться завтра.
Каждый день генерировал «цель дня»: пройти Х упражнений, дать Х правильных ответов. Если брать все сочетания, то возможны 15 различных целей дня. Плюс в настройках можно выбрать их сложность.
Ввел понятие «ударный темп». Это количество дней подряд, когда цель дня выполнялась. Если пропустить день – ударный темп обнуляется.
В процессе выполнения упражнений отображается прогресс цели дня, а иногда выскакивает лис и дает мотивирующие комментарии.
Акцент на прогрессе цели дня
Уведомления
Изначально казалось, что подключить пуши не получится.
Но в результате, с помощью стороннего плагина Construct, сервиса OneSignal и такой-то матери – я их все же прикрутил.
Пуш-уведомления дают возможность вернуть студентов, которые пару дней не открывали приложение. А еще удобно уведомлять старых пользователей о выходе новой версии.
Из интересного – я не стал делать безликие триггерные пуши в духе «Пора заниматься!». Вместо этого рассылал уведомления вручную, каждый раз выбирая время и инфоповод.
Пуш на 14 февраля 
Пуш в начале пандемии
От 8 до 20% студентов, получавших такие уведомления, – тут же открывали приложение.
Оценки и отзывы
Когда делаешь коммерческое приложение в рамках работы – относишься к оценкам как к одной из многих метрик продукта. Но когда делаешь приложение «для души» – отзывы превращаются в значимый эмоциональный фактор. Они действительно могут мотивировать работать дальше.
Душевные отзывы
Ну или демотивировать.
Первая единица
Потому что даже одна единица сразу сбивает рейтинг приложения. И тогда думаешь: «Зачем мне это всё? Можно ведь вечер и лучше провести, а не возиться с вот этим всем».
Пару оценок удалось исправить, отвечая пользователям. Но в целом не стоит рассчитывать на объективность – люди могут пользоваться приложением и написать радостный отзыв, но при этом поставить тройку, потому что «могло бы быть и получше».
Выводы
В статье было много практичных мыслей, поэтому позвольте теперь поделиться общими впечатлениями.
В который раз я убедился, что лучший способ чему-то научиться – попробовать сделать это на практике. Пройти путь от начала до конца, пусть даже «на минималках».
К примеру, когда нужно объяснить правила настольной игры новичку – можно долго про них рассказывать, пока вообще не перехочется играть. Или просто начать играть, разбираясь по ходу дела.
С приложением (да и с жизнью в целом, наверное) – такая же история. Если выяснять все возможные проблемы и подводные камни, то начинать что-то делать страшно. Но если позволить себе чуть-чуть пофантазировать, немного изучить вопрос, сделать небольшой прототип… можно очнуться, когда все уже получилось.
Еще хочу сказать, что это большое удовольствие – делать что-то в одиночку. На работе мне достаточно написать задачу – и целая команада профессиональных разработчиков воплотит ее в лучшем виде: учтет все кейсы, архитектуру, адаптивность, секьюрность, нагрузку. Но когда работаешь в одиночку, то вообще не нужно писать задач, ждать конца спринта, что-то кому-то объяснять. Просто воплощаешь свой вижн – напрямую, непосредственно. Это увлекает. Думаю, что-то подобное чувствует художник, работая над картиной.
Спустя год
Прошло уже больше года с момента релиза приложения. Сейчас у него около 12 000 установок и средняя оценка «4,6». Какое-то время я еще занимался приложением: рассылал пуши, правил баги, добавил несколько фич по просьбе студентов.
Но потом забросил и только иногда отвечаю на отзывы.
В начале пандемии был пик скачиваний, но из-за отсутствия обновлений – приложение потихоньку теряет позиции, а с ними и количество ежемесячных установок.
Ежемесячные установки за весь период жизни приложения
В общем-то, можно было бы и дальше работать над ним, но без аналитики непонятно куда двигаться и как влияют доработки.
Конечно, есть и очевидные улучшения. Например, можно записать качественную озвучку с профессиональным диктором, носителем языка. Или нанять хорошего UI-дизайнера. Но и то, и другое будет стоить по несколько тысяч долларов. Не совсем понятно, зачем этим сейчас заниматься.
Поэтому я довольствуюсь тем, что получил ценный опыт и сделал что-то полезное для людей. Может быть, когда-нибудь появится вдохновение, и я продолжу эту историю.