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

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

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

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

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

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

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

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

Работаем через промежуточный API. Прямой доступ из приложения в 1С или ERP мы закрываем. Такой слой позволяет переживать обновления учётной системы и её плановые остановки: приложение продолжает собирать данные и досылает их позже. Отдельно согласуем, какие данные приложение имеет право читать и менять — на производстве это вопрос допуска.

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

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

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

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

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

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

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

Сканирование кодов делаем камерой, для RFID нужен либо телефон с NFC, либо внешний считыватель. Второе означает выбор конкретной модели оборудования до начала разработки: у считывателей разные протоколы и SDK. Список поддерживаемых устройств фиксируем в договоре, чтобы через полгода закупка не привезла модель, с которой приложение не работает.

Готовим описание того, какие данные приложение собирает, куда отправляет и где хранит, плюс схему доступов и порядок отзыва прав. Обычно этого достаточно для согласования. Если предприятие требует внутреннего размещения, сервер разворачиваем в вашем контуре, а приложение раздаём через внутренний канал распространения вместо публичного стора.

Не всегда. Корпоративное приложение раздаётся через внутренние программы распространения Apple и Android без публикации в сторе. Это снимает ревью и ускоряет выпуск правок, но требует управления сертификатами и устройствами. Выбор между публичным стором и внутренним каналом делаем по числу устройств и по требованиям безопасности.

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