Разработка кроссплатформенных приложений
в Воронеже
и масштабируйтесь.
Что даёт кросс-платформенное приложение
Один код на две платформы
Экраны и логика пишутся раз и работают на обоих магазинах.
Выход одновременно
Обновление доходит до всех пользователей в один день.
Одна команда
Задачи не делятся между двумя группами разработчиков.
Поддержка дешевле
Правку вносят один раз, и она уходит на оба магазина.
Быстрая проверка идеи
Первая версия выходит раньше, и рынок отвечает на неё раньше.
Кому подходит кросс-платформенное приложение
- Один главный сценарий
- Выход в оба магазина
- Быстрые правки
- Вход и профиль
- История операций
- Оплата и статусы
- Одна сборка на парк
- Права по ролям
- Обмен с учётом
Как устроена работа над общим кодом
Стоимость кроссплатформенного
приложения в Воронеже
Мы оцениваем проект исходя из целей: список галочек в перечне функций ничего не решает.
Цены указаны без НДС. НДС по ставке 5 % предъявляется дополнительно и включается в счёт.
Больше возможностей для вашего проекта
- Интернет-магазины
- Недвижимость
- Здравоохранение и стоматология
- Рестораны и кафе
- Салоны красоты
- Образование
- Строительство
- Юридические услуги
- Туризм и гостиницы
- Логистика
- Дизайн интерьеров
- Ремонт квартир
- Автосервисы
- Маркетплейсы
- Консалтинг
- Фотографы
Обсудим проект?
FAQ
Если не нашли ответа — напишите нам на info@toimi.pro.
Можем ли мы запуститься сразу на iOS и Android?
Да, именно так мы и работаем. Используем общий код, чтобы избежать дублирования и синхронизировать функциональность между платформами.
Приложение будет выглядеть нативно или как веб-обертка?
Мы используем нативные API и взаимодействия там, где это действительно важно. Пользователь не заметит, что это кроссплатформа — и в этом фишка.
А если у нас уже есть прототип?
Мы проведем аудит и либо доработаем рабочее, либо переработаем то, что не выдерживает нагрузку. Чистая передача — часть процесса.
Вы берете на себя и бэкенд?
Да. Мы можем разработать API, подключиться к вашим системам или интегрировать сторонние сервисы — что бы ни потребовалось вашему приложению.
Можно ли перевести существующее приложение на общий код?
Можно: логику переносят, интерфейс собирают заново.
Когда это имеет смысл?
Когда две нативные сборки разошлись и поддержка стала дорогой.
Когда переводить не стоит?
Когда приложение живёт вокруг системных возможностей.
Сколько занимает перевод?
Сопоставимо с разработкой первой версии заново.
Что переносится проще всего?
Правила расчётов и работа с сервером.
Что приходится делать заново?
Экраны, анимацию и связки с системными возможностями.
Можно ли переводить по частям?
Часть экранов оставляют нативными и добавляют общие.
Что такое смешанный подход?
Нативное приложение с экранами на общем коде внутри.
Работает ли это на практике?
Работает, но усложняет сборку и отладку.
Как быть с данными пользователей при переходе?
Локальную базу переносят с проверкой на живых данных.
Что бывает при неверном переносе базы?
Люди теряют историю, и это видно в отзывах.
Нужно ли сохранять вход пользователей?
Токены переносят, чтобы люди не входили заново.
Как быть с подписками при переходе?
Состояние доступа держат на сервере.
Нужно ли предупреждать пользователей?
О крупном обновлении сообщают коротким пояснением.
Как быть с оценкой в магазине после перехода?
Резкие изменения интерфейса вызывают волну отзывов.
Как снизить недовольство?
Сохраняют привычные пути и названия разделов.
Нужно ли выпускать обновление постепенно?
Поэтапная раскатка ограничивает число задетых людей.
Как быть с откатом при проблемах?
Предыдущую версию держат готовой к публикации.
Нужно ли сохранять старый код?
Его держат в репозитории до устойчивой работы новой версии.
Как быть с двумя командами при переходе?
Нативные разработчики нужны на связках и на отладке.
Нужно ли переписывать сервер?
Сервер обычно остаётся прежним.
Как быть с аналитикой при переходе?
Названия событий сохраняют, иначе отчёты рвутся.
Нужно ли сравнивать показатели до и после?
Сравнение показывает, не потеряли ли пользователей.
Какие показатели смотреть?
Входы, удержание, сбои и завершённые действия.
Как быть с ростом сбоев после перехода?
Это ожидаемо в первые недели, и их разбирают быстро.
Нужно ли планировать запас на исправления?
Первый месяц после перехода держат резерв времени.
Как быть с размером сборки после перехода?
Он вырастет, и это учитывают.
Нужно ли предупреждать о росте размера?
Пользователей это волнует на мобильной сети.
Как быть с производительностью после перехода?
Её замеряют на слабых устройствах до выпуска.
Что делать при просадке скорости?
Узкие места переписывают нативно.
Нужно ли считать экономию после перехода?
Её считают по часам поддержки за квартал.
Через сколько виден выигрыш?
Через несколько выпусков, когда правки идут один раз.
Как принять решение о переходе?
Считают стоимость поддержки двух сборок против стоимости перевода.
Кто принимает решение?
Заказчик после расчёта обоих вариантов.
Что делать при сомнениях?
Переводят один раздел и смотрят на результат.
Сколько стоит такой пробный перевод?
Заметно меньше полного и даёт ответ по фактам.
Смотрите также
Обновлено: