Перенести приложение и сохранить прогресс детей: как мы обновили KIT 4 KID
Ребёнок выполняет упражнение, родитель смотрит динамику, специалист настраивает игры. Для всех троих KIT 4 KID выглядит как единый продукт. Внутри это система, где любое крупное обновление затрагивает игровые механики, профили, статистику и накопленные данные.
Мобильное приложение уже работало на iOS и Android, когда команда KIT 4 KID обратилась в Qtim. Нужно было пересобрать интерфейс, перенести клиентскую часть с React Native на Flutter, обновить бэкенд и подготовить основу для новых функций. При этом пользователи не должны были потерять привычные сценарии и историю занятий.
Я Антон Фокин, CEO Qtim. Расскажу, как мы обновляли действующий EdTech-продукт для детей с особенностями развития и почему такой проект начинается задолго до новых экранов.
Работающий продукт уже упирался в старую архитектуру
KIT 4 KID — мобильное приложение для ABA-терапии детей с РАС и другими особенностями развития. Ребёнок проходит игровые задания, а родители и специалисты настраивают занятия и следят за результатами.
К моменту старта у клиента уже были методология, контент, игровые сценарии, база пользователей и данные о прогрессе. Их нельзя было отбросить и собрать продукт заново. Основную логику обучения, профили, статистику и привычный порядок действий требовалось сохранить.
Старая версия постепенно ограничивала развитие. Интерфейс выглядел неоднородно, навигация нуждалась в упрощении, игровые механики требовали доработки, а поддержка телефонов и планшетов добавляла расхождения между экранами. Одновременно рос технический объём: новая функциональность зависела от мобильной архитектуры, API и инфраструктуры.
Поэтому проект разбили на этапы. Сначала привели в порядок код и окружение, затем провели аудит, собрали дизайн-концепцию, обновили все экраны, перенесли приложение на Flutter и переработали серверную часть. После основного релиза продолжили развивать механику обновлений и монетизацию.
Редизайн начался с репозитория, автобэкапов и S3
Первым этапом стала инфраструктура. Мы развернули GitLab, перенесли код в репозиторий клиента, настроили автоматический деплой, подняли S3-совместимое хранилище для резервных копий и добавили автобэкап базы. Параллельно исправляли ошибки в действующей версии.
До крупных изменений команда получила контролируемую среду, управляемый выпуск сборок и резервные копии данных.
После этого дизайнеры провели аудит интерфейса и разобрали трёх прямых конкурентов. Результатом стала единая система: пользовательские потоки, палитра, типографика, иконки, состояния компонентов и правила их применения. Концепцию собрали в Figma и отдельно представили команде клиента.
Три роли, три сценария: ребёнок играет, взрослые оценивают прогресс
У KIT 4 KID три пользовательских сценария. Ребёнок взаимодействует с играми и должен понимать следующий шаг без длинной инструкции. Родителю важно настроить занятия и увидеть динамику. Специалисту нужны данные по играм и уровням, чтобы оценивать прогресс и корректировать программу.
На момент подготовки кейса в приложении шесть игр: «Сопоставления», «Различения», «Категории», «Последовательности», «Глаголы» и «Сюжеты». В каждой игре своё количество уровней: например, в «Сопоставлениях» их пять.
В самих играх изменения были точечными. Текст задания закрепили над упражнением, а варианты ответа расположили у нижнего края экрана. Так до них легче дотянуться: ребёнку не нужно вести палец через весь экран.
В старой версии профиль взрослого и карточка ребёнка визуально смешивались, а действие «Добавить / выбрать ребёнка» объединяло два разных сценария. Сводка по играм показывала проценты без пояснения, что они означают и можно ли открыть подробности.
В новой версии выбор ребёнка отделили от добавления нового: для каждого действия появился отдельный элемент. В сводке сделали карточки игр и фильтр по уровням сложности. По каждой игре открывается список занятий с датой, временем и количеством заданий, выполненных без ошибок. Родитель задаёт нужный уровень, отмечает занятия и отправляет подборку на электронную почту.
Все UX-решения команда согласовывала с экспертом клиента, который работает с детьми с РАС. Благодаря этому интерфейс учитывал реальные особенности аудитории и общие правила мобильного дизайна.
UI-kit связал телефоны, планшеты и игровые состояния
После концепции мы переработали экраны для смартфонов и планшетов с разрешением 1280 × 800. Отдельно собрали UI-kit: компоненты, цветовые токены и анимации состояний для интерактивных элементов.
В игровом приложении состояние компонента влияет на смысл. Кнопка должна одинаково вести себя в разных заданиях, ошибка — давать узнаваемую обратную связь, переход между уровнями — не менять правила без предупреждения. UI-kit закрепил эти решения и сократил расхождения между модулями.
Он же упростил дальнейшую разработку. Новый экран можно собирать из уже согласованных компонентов, а изменение цвета, состояния или поведения не приходится повторять в каждом разделе отдельно.
Переезд с React Native на Flutter без потери логики
В React Native игровая логика с анимациями, перетаскиванием объектов и звуком упиралась в производительность JS-моста. Через него же загружался контент, который приложение сохраняло файлами в кеш-директорию без локальной базы. Поддержку усложняли большой объём шаблонного Redux-кода и нетипизированная навигация по строковым именам экранов.
Flutter отрисовывает интерфейс через Impeller без JS-моста. Dart добавил типизацию, Riverpod и Freezed — кодогенерацию, а go_router — типобезопасные маршруты. Для контента появилась полноценная локальная база. Одна кодовая база обслуживает iOS и Android, поэтому изменения можно выпускать синхронно и поддерживать сразу на двух платформах.
Главным риском была совместимость. Перенос охватывал авторизацию, профили детей, прогресс, статистику и шесть игровых механик: глаголы, категории, сопоставление, «Найди отличия», истории и порядок действий. Их поведение задаёт контент с сервера: старый бэкенд возвращает JSON с описанием того, что и как показывать в приложении.
При переписывании клиента формат данных менять было нельзя, иначе перестал бы работать уже созданный контент. Во Flutter каждый тип игры вынесли в отдельный класс, а нужную реализацию приложение выбирает через стратегии и фабрики по описанию из JSON.
Проект прошёл три этапа. Сначала заложили архитектуру и собрали прототип базовой функциональности. Затем перенесли модули и подключили API. В конце протестировали и оптимизировали приложение, после чего опубликовали его в App Store и Google Play.
Перенос пользовательских данных не потребовался. База примерно из 60 таблиц сохранила прежнюю схему, поэтому профили детей, прогресс и статистика остались на месте. Поверх неё переработали API и подключили Flutter-приложение. Последующие изменения структуры оформляли отдельными миграциями.
Статистика занятий сначала записывается в локальную базу на устройстве, а затем синхронизируется с сервером. Ребёнок может заниматься без интернета: при восстановлении соединения накопленный прогресс передаётся в систему.
Новый бэкенд разложили на девять API-модулей
Одновременно с мобильным приложением мы пересобрали бэкенд на NestJS, TypeORM и MySQL. Серверную логику разделили на девять API-модулей: среди них авторизация, профили детей, игры, аналитика, медиа, локализация и администрирование.
API описали в Swagger. Для основных сценариев добавили модульные и интеграционные тесты; по данным проектной команды, покрытие превысило 70%.
В обновлённой версии появились регистрация по электронной почте и отправка статистики пользователю. На четвёртом уровне игры «Различения» команда добавила механику исключений.
После релиза клиент получил контроль над версиями приложения
Мобильный релиз не завершает миграцию. Пользователи обновляются в разное время, а новая функция может зависеть от версии API или структуры данных. Поэтому мы добавили два режима обновления: обязательный и рекомендуемый. Клиент управляет ими через админ-панель, а пользователь видит соответствующее сообщение в приложении.
Инфраструктуру перенесли на Timeweb и зарубежный сервер, автоматизировали деплой и резервное копирование. Для защиты от DDoS-атак подключили NGENIX. Теперь код хранится в репозитории клиента, релизы проходят через CI/CD, база копируется автоматически, а устаревшую версию приложения можно вывести из обращения.
Две платформы теперь развиваются из одной кодовой базы
После основного релиза у команды KIT 4 KID осталось следующее:
- iOS и Android развиваются из одной Flutter-кодовой базы;
- профили, прогресс и статистика связаны с новым приложением через переработанный API;
- интерфейс смартфонов и планшетов собран на едином UI-kit;
- серверная часть разделена на документированные модули;
- сборки, деплой и резервное копирование автоматизированы;
- обязательные и рекомендуемые обновления настраиваются через админ-панель.
Отдельно переработали работу с медиа. Старая версия при каждом открытии запрашивала у сервера полные списки изображений, игр и других материалов, затем заново догружала файлы. Новая версия скачивает медиа один раз — параллельно, с ограничением количества одновременных запросов, — и хранит реестр в локальной базе. При следующих запусках приложение берёт файлы из кеша и обновляет только изменившиеся, поэтому они занимают в разы меньше времени.
На этой базе команда готовит следующий этап: новые игры, уровни и способы оплаты.
Вот как в KIT 4 KID оценивают результат проекта:
Мы обратились к команде Qtim в 2025 году. На тот момент у нас уже было опубликованное приложение, которые мы сделали с другой командой, где получили максимально негативный опыт взаимодействия и качества работ. Мы искали новую команду, чтобы исправить ошибки предыдущей команды, перевыпустить дизайн и для дальнейшего развития нашего проекта.Здесь отлично подходит выражение «небо и земля», ведь уже с первых зумов с командой Qtim мы поняли «а что, так можно было?»))) Прекрасный опыт коммуникации, внимательные ребята и талантливые разработчики. Все в срок, четко и по делу. Нам была очень важна прозрачность процессов и гарантии — здесь мы получили все что хотели. Очень радует вовлеченность команды, а не просто «техничное исполнение задачи».В результате мы сделали то, за чем пришли и продолжаем сотрудничать. И будем обращаться к команде с новыми проектами и рекомендовать — однозначно.
Подписка и четыре новые игры: следующий этап проекта
Следующий этап — монетизация: подписка, платный контент, пробный период и платежи. Параллельно в разработке четыре новые игры: «Формы», «Цвета», «Схемы» и «Цветовые схемы», а также новые уровни, пуш-уведомления и письма.
В KIT 4 KID порядок работ определили профили детей и их прогресс. Сначала мы зафиксировали методологию, данные и привычные действия пользователей. Затем перестроили интерфейс, мобильный стек и серверную архитектуру вокруг этих сценариев.
Если продукт вырос из текущей архитектуры, можно разобрать с нами сценарии миграции, риски для данных и состав первой версии после перехода.