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