Разработка
мобильных приложений
в Самаре

Объем задач, количество интеграций и насколько быстро вы отвечаете на наши уточнения. Мы всегда оставляем немного пространства для финальных правок и тестов — чтобы не срывать сроки и спокойно довести все до ума.

Зависит от платформы (iOS, Android, Flutter), функциональности и технической архитектуры. Точную сумму сможем назвать после того, как обсудим задачи.

Да, и это даже удобно: логика будет общей, и ничего не придется клеить потом на ходу. Мы делаем и сайты, и приложения — проектируем все целиком, чтобы все работало как часы.

Не исчезаем :) Поддерживаем, обновляем под новые версии iOS и Android, следим за стабильностью и развиваем проект дальше. Для нас запуск — это точка роста.

Да, и без боли. Мы сразу строим архитектуру так, чтобы было удобно масштабироваться. Нужен чат? Онлайн-оплата? Темная тема? Все добавляется по мере роста.

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

Через справочник на стороне сервера и запрос из приложения по номеру. Сканирование номера камерой ускоряет ввод и уменьшает число ошибок, распознавание проверяем на реальных табличках и наклейках: они бывают затёртыми и под углом. Результат подбора кэшируем, чтобы механик в цеху не терял его при просадке связи.

Встроенные покупки Google Play российским разработчикам недоступны, поэтому расчёты строим на СБП и эквайринге с картами «Мир», иногда на счёте, выставляемом в приложении и оплачиваемом отдельно. Для B2B чаще нужен второй вариант: приложение показывает счёт и статус его оплаты, а деньги идут по обычному банковскому пути.

Для российской аудитории да, иначе часть пользователей не установит приложение. Держим сборки синхронно с App Store по версиям и набору функций. Для дилерских сетей это ещё и вопрос управляемости: обновление через RuStore доходит быстрее, чем ожидание ревью Apple, и срочную правку иногда доставляют через него первым.

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

Сжимаем на устройстве перед отправкой, держим очередь загрузки и локальные копии до подтверждения сервера. Для гарантийных заявок фотофиксация обязательна, поэтому дополнительно проверяем, что снимок привязан к заявке и не теряется при закрытии приложения. Срок хранения локальных копий оговариваем: иначе за сезон память устройства заполняется.

База с персональными данными и резервные копии остаются на серверах в России. Отдельно проверяем сторонние SDK: аналитика и крэш-репортеры по умолчанию нередко отправляют идентификаторы за рубеж. Для приложений с данными клиентов автосервиса этот пункт закрываем до релиза.

Как правило да, и это два разных приложения либо одно с жёстким разделением прав на сервере. Клиент видит свои заявки и статусы, сотрудник — очередь работ и склад. Разделение проверяется на сервере при каждом запросе; скрытие элементов интерфейса удобно пользователю и защитой не является.

Через промежуточный API, который синхронизируется с учётной системой по расписанию и по событию. Такой слой позволяет пережить обновление системы дилера и её плановые остановки: приложение продолжает работать на кэше и догоняет данные позже. Прямая интеграция из приложения в учётную систему ломается при первом же её обновлении.

Считаем спринтами по объёму сценариев и интеграций. Первый спринт даёт работающий каркас с одним сквозным сценарием — например, записью в сервис со статусом. Дальше расширяем по приоритетам. Смету фиксируем до начала, работы вне согласованного объёма оцениваем отдельной сметой заранее.

По договору сопровождения — мы: обновления под новые версии iOS и Android, продление сертификатов подписи, наблюдение за крэшами и временем запуска, правки по заявкам. Срок сертификата подписи ведём в календаре: его истечение блокирует выпуск обновлений при полностью рабочем приложении.

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

Начинаем с аудита кода и аккаунтов публикации. Частая находка — аккаунт разработчика оформлен на прежнего подрядчика, и это блокирует релизы до передачи прав. По итогам аудита даём две сметы: доработка и разработка заново, с учётом стоимости сопровождения текущего кода. Выбор за вами, и он обычно очевиден из чисел.

Исходный код в вашем репозитории, сборки, доступы к аккаунтам, документация по API и по протоколу синхронизации с учётной системой. Протокол синхронизации описываем подробно: без него следующая команда сломает офлайн-режим первой же правкой, а обнаружится это только в цеху.

Для дилерских сетей это обычно следующий шаг: список принадлежащей клиенту техники, пробег или наработка, сроки регламентного обслуживания, история работ по каждой единице. Приложение начинает напоминать о ТО заранее, и сервис получает предсказуемую загрузку вместо аварийных обращений. Данные о наработке подтягиваются из учётной системы либо вводятся на приёмке; источник фиксируем на этапе проектирования.

Через адресные уведомления по истории обслуживания: напоминание о регламентной работе, предложение сезонной подготовки, информирование о доступных слотах. Такие уведомления требуют согласия пользователя и раздельных каналов для сервисных и рекламных сообщений, иначе отписка убивает оба сразу. Эффект считаем по числу записей, пришедших из уведомления.